sql慢查询排查需按标准四步走：先开启合理阈值的慢查询日志并指定安全路径；再从真实日志提取带实际参数的 SQL 分析频次与扫描行数；接着用 EXPLai N 紧盯 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
基本上就这些。流程不复杂，但每一步漏掉都可能绕半天弯路。
