SQL慢查询排查需按标准四步走：先开启合理阈值的慢查询日志并指定安全路径；再从真实日志提取带实际参数的SQL分析频次与扫描行数；接着用EXPLAIN紧盯type、key、Extra三列定位执行瓶颈；最后依场景建复合索引、精简字段、优化子查询并验证效果。
SQL慢查询排查不是靠猜，而是有标准节奏：先让问题“显形”，再定位根因，最后验证效果。跳过前面步骤直接改SQL或加索引，90%会白忙活。
第一步：必须开慢查询日志，且设对阈值
不开启日志，等于闭眼修车。线上默认10秒才记日志，完全没用。
- 生产环境建议从0.5秒起步（高并发可压到200ms），别一上来就设0.1——日志爆炸、磁盘撑爆、运维翻脸
- 配置方式（my.cnf）：slow_query_log = 1，long_query_time = 0.5
- 顺手打开log_queries_not_using_indexes = ON，能抓到“明明有索引却没走”的隐形坑
- 日志路径务必指定非系统盘，避免写满导致MySQL挂掉
第二步：看真实慢日志，还原真实参数
不要拿开发环境随便拼的SQL去explain——参数不同，执行计划可能天差地别。
- 从慢日志里复制完整SQL，注意检查WHERE条件里的实际值（比如
tenant_id = 123456789而不是tenant_id = ?） - 确认该SQL在日志中出现频次和平均耗时，优先处理高频+高耗时组合
- 留意Rows_examined（扫描行数）是否远大于Rows_sent（返回行数），差距大说明过滤效率低
第三步：用EXPLAIN看执行计划，盯死三处
EXPLAIN不是扫一眼就行，重点只看三个位置：
- type列：出现ALL（全表扫描）或index（全索引扫描）基本就是瓶颈，要立刻查索引是否缺失或失效
- key列 & possible_keys列：如果possible_keys有值但key为空，说明索引存在但没被选中，常见于类型不匹配、函数包裹字段、隐式转换
- Extra列：出现Using filesort或Using temporary意味着排序/分组无法走索引，需调整ORDER BY字段或加覆盖索引
第四步：针对性优化，避开典型误区
优化不是堆索引，也不是硬改SQL，关键是匹配场景：
- WHERE + ORDER BY组合查询，优先建复合索引（遵循最左前缀），比如
WHERE status=1 AND tenant_id=123 ORDER BY created_at DESC，索引应为(status, tenant_id, created_at) - 别盲目
SELECT *，尤其关联多表时——只取需要字段，减少网络传输和回表开销 - 子查询不是原罪，但相关子查询容易触发嵌套循环，可尝试转为JOIN或窗口函数（如ROW_NUMBER()替代TOP 1子查询）
- 加完索引一定要用相同参数再EXPLAIN一次，防止误判；也别留着长期不用的索引，它们拖慢INSERT/UPDATE
基本上就这些。流程不复杂，但每一步漏掉都可能绕半天弯路。
