MySQL 慢查询排查：从 show processlist 到 EXPLAIN 和索引优化的完整路径：我踩过几次坑后整理出来的顺手做法

上次我在一套读多写少的业务里做调整，表面上只是一个列表页慢，最后查下来，根子其实是索引顺序、回表次数和慢查询日志这三件事一起在拖后腿。

这里通常就是分水岭，前后差别很明显。

先把话说直一点：MySQL 慢查询排查：从 show processlist 到 EXPLAIN 和索引优化的完整路径 不是把参数堆满，也不是照着别人博客抄一遍就算完。真正起作用的，常常是一些小地方。

这一步如果省掉，后面多半要补课。

排错的时候，我通常会把最近改动过的东西重新过一遍，再去看错误日志和最慢的那一段链路。SET GLOBAL slow_query_log = 'ON'; 这类检查可以顺手做一下，很多时候都能把方向先拉回来。

还有一个很现实的判断：线上事故通常没那么玄。很多事情不是系统自己坏掉，而是某个细节没对上，最后连锁反应把问题放大了。

如果要上生产，我一般会先过这几件事：先开慢查询，再谈优化。 先看最慢的那几条 SQL，不要平均用力。 能覆盖的就尽量覆盖，少让查询回表。

上线前最怕‘差不多’。差不多能跑、差不多稳定、差不多没事——这些词听着轻松，到了生产环境就不太轻松了。宁可提前把边界踩一遍，也别把问题留给回滚。

调整的时候，我更偏向小步来。一次只动一个地方，跑一轮，看看变化，再决定要不要继续。这样慢一点，但基本不会把自己绕进去。

这地方别急，慢一点反而更省事。

如果一口气动太多，事后很难判断是谁在起作用。真正难的不是改，而是改完之后还能说清楚为什么这样改。

我一般不会一上来就改东西。先看现象：是慢、是抖、是偶发错误，还是某个点一直在重复出事。这个判断比后面的操作更重要，因为方向一旦错了，后面改得越多越乱。

EXPLAIN SELECT .. 
这一步最值钱的其实不是技巧，而是克制。把边界看明白，别急着往里冲。很多问题看着像配置，最后发现根本不是配置，而是资源、数据分布或者调用顺序先出了问题。
 
几个细节我现在会特别留意：索引不是越多越好，写入压力会先反咬你一口。 联合索引顺序一旦排错，后面补救成本很高。 只看执行计划不够，最好连真实 SQL 和数据分布一起看。
 
这些话听起来不花哨，但多数问题最后都落在这里。越是看着不起眼的地方，越容易影响最终结果。
 SHOW INDEX FROM your_table; 
真要动手，我一般会先把几件基础事情抄下来：EXPLAIN SELECT ..、SHOW INDEX FROM your_table;、SHOW VARIABLES LIKE 'slow_query_log';。这些命令不新，但能帮你先确认问题在不在你以为的位置。
 
有时候只要把这一步做对，后面就轻很多。反过来，如果一开始就凭感觉调，最后你会发现自己一直在兜圈子。
 
如果你也在处理 MySQL 慢查询排查：从 show processlist 到 EXPLAIN 和索引优化的完整路径，我更倾向于先照着这个思路把现象过一遍，再决定要不要动手。很多时候，想清楚比做得快更重要。
 SHOW VARIABLES LIKE 'slow_query_log'; SET GLOBAL slow_query_log = 'ON';

我一般会在这里停一下。