慢查询治理三件套：EXPLAIN、索引与改写，一次把顺序讲清楚

结论先行

慢查询治理不是「加索引」三个字能糊弄的，正确顺序是：先定位（EXPLAIN + 慢日志）→ 再判断（是索引问题还是写法问题）→ 最后才是加索引或改写 SQL。我 3 年在 DBA 岗位上踩过的坑，绝大多数都败在「上来就加索引」这一步。

一、定位：EXPLAIN 看什么

拿到一条慢 SQL，先 EXPLAIN，重点看 5 个字段：

• type：ALL 直接判死刑；index 也差；range/ref/eq_ref 才算及格；const 最好。
• key：实际走的那个索引，不是候选索引。这里 NULL 就说明全表扫。
• key_len：判断联合索引用了几个前缀列。例如 (a, b, c) 三列，key_len 只到 b 说明 c 没参与。
• rows：扫描行数的估算，注意是估算不是实际值，别当精确数字看。
• Extra：Using filesort / Using temporary 出现基本可以判定要优化；Using index 是好信号（覆盖索引）。

我个人的一个习惯：EXPLAIN 之外，再看一次 EXPLAIN ANALYZE（MySQL 8+），它会给真实耗时和实际扫描行数，比估算值靠谱得多。

二、判断：是索引问题还是写法问题

这一步很多人跳过，直接跳到加索引，结果加完还是慢。常见「看似索引问题、其实是写法问题」的场景：

1. 对索引列做函数运算：WHERE DATE(create_time) = '2025-01-01' 索引直接失效，改成范围 create_time >= '2025-01-01' AND create_time < '2025-01-02'。
2. 隐式类型转换：phone 是 varchar，SQL 里写 WHERE phone = 13800000000（数字），索引失效。
3. OR 连接非索引列：WHERE a = 1 OR c = 2，c 没索引，整个走全表。
4. != / NOT IN / IS NOT NULL：优化器经常放弃索引。
5. LIMIT 优化陷阱：ORDER BY create_time DESC LIMIT 100，如果 create_time 有索引，应该直接走索引倒序，不需要 filesort；如果 EXPLAIN 显示 Using filesort，多半是索引列和排序列不一致，或者排序方向反了（索引是 ASC 你要 DESC）。

三、加索引的正确姿势

• 单列索引优先看选择性（distinct count / row count），选择性太低（比如 status 只有 0/1）加索引意义不大。
• 联合索引顺序：等值列在前，范围列在后；高频过滤列在前。
• 覆盖索引：SELECT 的列尽量都在索引里，能省掉回表。EXPLAIN 里 Extra 出现 Using index 就是覆盖。
• 索引不是越多越好：每条索引都增加写放大，我见过一张表 11 个二级索引，INSERT 吞吐直接腰斩。

四、一个真实数据点

某订单表 8000 万行，WHERE user_id = ? AND status IN (1, 2) ORDER BY create_time DESC LIMIT 20，原索引 (user_id, status)，EXPLAIN 显示 rows=120 万、Using filesort。改成 (user_id, status, create_time) 三列联合索引后，rows 降到 80，Extra 出现 Using index，P99 从 320ms 降到 6ms。

五、踩坑清单

1. 只信 EXPLAIN 的 rows，不看实际执行时间——估算值可能差 10 倍。
2. 加完索引没 ANALYZE TABLE，统计信息没更新，优化器还是走老路。
3. 生产直接 ALTER TABLE 加索引，8000 万行的表锁了 40 分钟——应该用 Online DDL 或 gh-ost。
4. 把 EXPLAIN 里的 type=index 当成「走了索引」，其实是全索引扫描，比全表扫还慢。
5. 只优化单条 SQL，不看 QPS 高的短查询——单条 5ms × 1 万 QPS = 每 50ms 一个慢查询，加起来才是真凶。

总结

顺序不能乱：先 EXPLAIN 定位，再判断是索引还是写法，最后才动手。加索引前问自己三个问题：选择性够吗？顺序对吗？写放大能接受吗？