记录一次使用覆盖索引解决elastic-job慢SQL的问题
2020-05-19 本文已影响0人
和平小花花
我们项目用到了一个当当的elastic-job分布式任务调度统计。有一条语句一直报慢SQL,慢SQL设置为超过1秒,SQL语句如下:
SELECT
original_task_id
FROM
JOB_STATUS_TRACE_LOG
WHERE
task_id = 'com.jzy.sup.job.server.job.CallBackBatchSimpleJob@-@0@-@READY@-@172.22.2.17@-@1'
AND state = 'TASK_STAGING'
数据量:

首先查看where 条件已有索引,

,所以查询是用到了索引。
但是为啥还会慢呢,结合《高性能MySql》书中介绍的InnoDB的索引原理,分析到,及时用到索引,但二级索引保存的是聚簇索引的主键值,所以查询original_task_id的时候还是需要通过主键再获取需要的结果。相关的值非常大,所以花费大量的时间。同时书中也给出覆盖索引的概念,参考如下照片。


分析得出将original_task_id也加入索引应该就能达到覆盖索引所描述情况。如下图增加索引:

对比增加索引前后的explain,发下增加后Extra多了UsingIndex描述,证明覆盖索引生效。
增加索引之前

增加索引之后

观察阿里云后台监控数据,发现缓存池页扫描直线下降,同时CPU消耗页下降60%。查询速度得到提升,再没有报相关的慢SQL。


