SQL慢查询排查按三步进行：先通过慢查询日志定位真实慢SQL，再用EXPLAIN分析执行计划，最后验证索引与结构是否合理；每步需严格闭环验证。
SQL慢查询排查不是靠猜，而是按顺序抓关键证据：先确认它真慢、再看它怎么慢、最后判断为什么慢。核心逻辑就三步——日志定位 → 执行计划分析 → 索引与结构验证。
第一步：让数据库自己“报错”——开启并读取慢查询日志
不看日志就调优，等于蒙眼修车。必须先让 MySQL 把慢的 SQL 记下来：
- 临时开启（测试环境快）：
SET GLOBAL slow_query_log = 1;SET GLOBAL long_query_time = 0.5;（注意：0.5 是最小有效值，MySQL 不支持 0.1 秒级精度） - 永久生效（生产环境必做）：在
my.cnf加三行：slow_query_log = 1slow_query_log_file = /var/log/mysql/slow.loglong_query_time = 0.5 - 别漏掉这个开关：
log_queries_not_using_indexes = 1，能帮你揪出“明明有索引却没用”的隐形问题 - 日志里重点盯三项：Query_time（真实耗时）、Rows_examined（扫描行数）、SQL 模板本身（注意参数是否被泛化）
第二步：还原真实现场——用 EXPLAIN 看执行计划
不能拿开发环境里带 LIMIT 的简化版 SQL 去 explain，必须用慢日志里记录的**完整语句 + 实际参数**还原执行场景：
- 执行
EXPLAIN FORMAT=JSON SELECT ...（JSON 格式信息更全，尤其看actual_rows和预估偏差） - 重点关注这几列：
• type：出现ALL（全表扫描）或index（全索引扫描）基本就是瓶颈；
• key 和 possible_keys：实际用了哪个索引？有没有更优索引没被选中？
• rows：MySQL 预估要扫多少行？如果远大于结果集，说明索引效率低或统计信息不准；
• Extra：出现Using filesort或Using temporary表示排序/分组被迫走磁盘，得加覆盖索引
第三步：查索引和数据结构——验证“为什么没走索引”
很多慢查询不是没建索引，而是索引被悄悄绕过了。常见失效原因直接对应字段设计和写法：
-
隐式类型转换：比如
WHERE mobile = 13812345678（mobile 是 varchar），MySQL 会放弃索引转成全表扫描 -
函数操作字段：如
WHERE DATE(create_time) = '2025-12-01'，索引无法下推，应改写为create_time >= '2025-12-01' AND create_time - 前导通配符：LIKE '%abc' 无法使用 B+Tree 索引，考虑全文索引或倒排表
-
联合索引顺序错位：索引是
(a,b,c)，但查询只用WHERE b = ?，那 a 没出现在条件里，索引就失效 - 检查外键字段：像
order.user_id关联user.id，如果user_id没单独建索引，JOIN 就可能变嵌套循环+全表扫描
第四步：验证与闭环——改完必须回归验证
加了索引或改了 SQL，不代表就快了。必须闭环验证：
- 在测试库用相同数据量、相同并发压测，对比
EXPLAIN中的rows和key是否变化 - 观察慢日志里该 SQL 是否不再出现，或
Query_time显著下降（比如从 2s → 80ms） - 注意缓存干扰：首次执行可能慢（磁盘IO），连续执行几次取稳定值；必要时用
SELECT SLEEP(0)清空 Query Cache（MySQL 5.7+ 已默认禁用） - 别忽略业务语义：有时候“优化”后 SQL 快了，但返回了错误数据（比如忘了加 WHERE 条件），务必核对结果集正确性
基本上就这些。不复杂，但容易忽略真实参数、索引失效细节和验证闭环。慢查询排查，本质是把黑盒执行过程一步步显性化。
