作者： navyaijm2017 原文来源：https://tidb.net/blog/06452af6

背景

9.10 号下午 18 点多，研发人员反馈有个服务的延时变高了，平时都是 2s 以下，突然变成了 10s 多

排查过程

• 登录集群的 dashboard，查看集群延时和慢查询确实都升高了，并且业务 SQL 慢的前后都有ANALYZE TABLEdip_saos_w.db_main_dw;操作，这个 Tidb 自动触发的收集更新表的统计信息的操作，如下图:

• 咨询了开发人员，db_main_dw这个表很早就上了，并且今天也没有做过任何业务上的调整，我试着调整 analyze 执行的频率，并且手动执行了一下今天变慢的 SQL，发现集群在没有做 analyze 的时候也很慢，如下图：

• 接着在群里咨询大家上图变慢的这个 SQL 今天有没有做过调整，得知下午上过线，这个 SQL 去掉了一个排序条件，ORDER BY c.priority desc, a.start_time变成了 ORDER BY a.start_time，调整前的 SQL 如下：

• 然后在 PingCAP 的技术支持群里咨询各位老师得知，原 SQL 语句使用了更为高效的索引。新的语句去掉了原先的排序列更换了为了低效的索引，所以执行变慢。（从最终的情况来看还是与执行计划不准确有直接关系）

TopN 和 Limit 下推规则

• 那么这个 SQL 还能再快嘛，8s 业务肯定是无法接受的，我想到了用 tiflash 加速，然后我把这个 SQL 涉及到的表都开启了 tiflash，explain 这个 SQL 发现查询竟然没有走 tiflash，然后我手动设置了 session 级别的set @@session.tidb_isolation_read_engines = "tidb,tiflash";把 tikv 禁止掉，再次 explain 这个 SQL 都走 tiflash 了，手动执行时间从 8s 将到了 500ms

tiflash 的用法

• 既然走 tiflash 查询效率提升比较明显，那就让开发人员改下 SQL，让这个查询强制走 tiflash，比较尴尬的是我们按官方文档把 SQL 调整了还是不能走 tiflash，强制走 tiflash 的 SQL 如下：

tiflash 的用法

• 上面问题反馈给群里 PingCAP 的技术支持小伙伴们然后继续排查，收集了表的健康度、表的统计信息、统计信息直方图，信息如下：

查看表的健康度信息

查看表的总行数以及修改的行数

查看统计信息直方图

• 通过上面信息发现这 3 个表的健康度都不高，官方建议健康度最好在 80 以上，所以我们先重新收集下表的统计信息，命令如下：

analyze 用法

• 然后再次执行发现还是无法走 tiflash，但是走 tikv 变快了，通过执行计划可以看到查询优化器用到了 TopN 和 IndexMergeJoin 这两个优化算子，执行计划如下：

• Tidb 虽然高度兼容 Mysql，但是有些用法和 Mysql 还是不一样的，包括 SQL 优化，下面是 SQL 优化相关的原理文章，要想把 Tidb 用好，SQL 的优化这块还需要从原理方面深入学习，SQL 优化原理相关
  

下面这三篇原理相关的文章可以了解下

说存储

说计算

谈调度

写在最后

特别感谢 PingCAP 的小伙伴们的大力支持，每次遇到问题会帮忙积极主动跟进处理，再次感谢李仲舒、王贤净、苏丹、高振娇。

更多学习和交流可以关注我公众号：