慢查询排查需按日志定位、真实参数还原、执行计划分析、索引验证四步闭环进行，关键在于使用带真实参数的SQL执行EXPLAIN并结合慢日志中的Query_time和Rows_examined综合判断。
排查 SQL 慢查询不是靠猜，而是靠证据链：从日志定位、参数还原、执行计划分析，到索引验证，环环相扣。关键不在于“会不会 explain”，而在于“有没有用对顺序”和“有没有带真实参数”。
一、先让慢 SQL 自己“开口说话”——开启并读懂慢查询日志
这是所有排查的起点，跳过这步直接 explain，就像没查病灶就开药方。
- 动态开启（立即生效，适合临时诊断）：
SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;
注意：long_query_time 实际按秒向下取整，0.5 表示记录 >0.5 秒的语句（含 0.5001 秒）。 -
配置文件永久开启（推荐生产环境）：
在 my.cnf 的[mysqld]下添加：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_queries_not_using_indexes = 1
后者能抓出“明明有索引却没走”的隐形问题。 - 看日志时盯紧三行：
Query_time（真实耗时）、Rows_examined（扫描行数）、SQL 本身（注意末尾可能带参数值，比如WHERE user_id=12345）。
二、别拿测试数据“演戏”——用真实参数还原 SQL 再 explain
同一句 SQL，参数不同，MySQL 可能走完全不同的执行路径。用 WHERE id = ? 这种占位符 explain，结果毫无参考价值。
- 从慢日志里复制完整 SQL，把实际参数填进去，例如：
日志中是SELECT * FROM orders WHERE status=1 AND create_time > '2025-11-01'，就拿这整条去 explain。 - 执行
EXPLAIN FORMAT=TRADITIONAL SELECT ...，重点关注：
type：ALL（全表扫描）或 index（全索引扫描）要立刻警惕；
rows：预估扫描行数，超 1 万建议优化；
key：实际使用的索引名，为空说明没走索引；
Extra：出现Using filesort或Using temporary是排序/分组性能瓶颈信号。
三、索引不是越多越好，而是“刚好够用”——聚焦命中与结构
加索引前先问三个问题：这个字段是否高频出现在 WHERE / JOIN / ORDER BY 中？当前 SQL 是否真能用上它？它的数据分布是否足够区分？
- 联合索引必须遵守最左匹配：建了
(user_id, status, create_time)，以下能命中：WHERE user_id = 100✅WHERE user_id = 100 AND status = 1✅WHERE user_id = 100 AND create_time > '2025-01-01'✅（但 status 不参与，create_time 无法用索引排序）WHERE status = 1❌（跳过最左列，索引失效） - 常见失效场景：
对索引列做函数：WHERE YEAR(create_time) = 2025→ 改成create_time BETWEEN '2025-01-01' AND '2025-12-31'；
前导通配符：name LIKE '%张'→ 无法用索引，考虑倒排或全文索引；
隐式类型转换：WHERE mobile = 13812345678（mobile 是 VARCHAR）→ 改成字符串'13812345678'。
四、别只盯着单条 SQL——结合上下文看整体影响
一条慢 SQL 可能只是表象，背后可能是锁争用、连接池打满、或者缓存穿透。
- 用
SHOW PROCESSLIST查实时阻塞：
看 State 列是否卡在Locked、Waiting for table metadata lock；
看 Time 列是否持续增长，确认是不是被长事务拖住。 - 用
SHOW STATUS LIKE 'slow_queries'看慢查询总次数，结合业务峰值判断是否集中爆发；
用SHOW VARIABLES LIKE 'long_query_time'确认当前阈值是否合理（高并发系统可设为 0.2～0.5 秒）。 - 如果某类查询高频且固定（如首页商品列表），别硬扛数据库，加 Redis 缓存结果，设置合理过期策略。
基本上就这些。流程不复杂，但容易忽略真实参数、日志聚合和锁上下文。动手前多看一眼 Rows_examined 和 Query_time，比调十次 explain 都管用。
