MySQL 慢查询排查四步法：从慢日志到索引优化

线上接口突然变慢，很多时候根源是一两条 SQL。与其凭感觉加索引，不如按固定步骤把问题找出来、验证掉。

1. 打开慢查询日志，先拿到证据

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SHOW VARIABLES LIKE 'slow_query_log_file';

把阈值设成 1 秒（或更低）跑一段业务高峰，日志里就会留下真正拖慢系统的语句。云数据库 RDS for MySQL 可以直接在控制台的「慢日志」页面查看和下载，不用登录主机。

2. 用 mysqldumpslow 聚合，找出最值得优化的语句

mysqldumpslow -s t -t 10 /var/lib/mysql/slow.log

-s t 按总耗时排序，-t 10 取前 10 条。优先处理「总耗时最高」的语句，而不是单次最慢的那条：一条 0.5 秒但每分钟执行上千次的 SQL，往往比偶发的 10 秒查询影响更大。

3. 用 EXPLAIN 看执行计划

EXPLAIN SELECT * FROM orders WHERE user_id = 1001 AND status = 'PAID' ORDER BY created_at DESC LIMIT 20;

重点看这几列：

• type：出现 ALL 表示全表扫描，至少要做到 ref 或 range。
• key：实际用到的索引，为 NULL 说明没走索引。
• rows：预估扫描行数，越大越危险。
• Extra：Using filesort、Using temporary 是常见的性能杀手。

4. 针对性加索引，再验证

上面的例子可以建联合索引，把等值条件放前面、排序字段放最后：

ALTER TABLE orders ADD INDEX idx_user_status_created (user_id, status, created_at);

建完再跑一次 EXPLAIN，确认 type 变成 ref、Extra 里的 filesort 消失，再对比慢日志里该语句的耗时。

几个常见的坑

• 对索引列做函数或隐式类型转换（如 WHERE DATE(created_at) = ...、字符串列传数字）会让索引失效。
• LIKE '%abc' 前缀模糊无法走 B+ 树索引。
• 索引不是越多越好，写多读少的表要控制数量，大表加索引尽量在低峰期，或使用 Online DDL。

按「慢日志取证、聚合排序、EXPLAIN 分析、加索引验证」这四步走，大多数慢查询都能在一小时内定位并解决。