结论先行
慢查询治理不是「加索引」三个字能糊弄的，正确顺序是：先定位（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+），它会给真实耗时和实际扫描行数，比估算值靠谱得多。
二、判断：是索引问题还是写法问题
这一步很多人跳过，直接跳到加索引，结果加完还是慢。常见「看似索引问题、其实是写法问题」的场景：
- 对索引列做函数运算：
WHERE DATE(create_time) = '2025-01-01'索引直接失效，改成范围create_time >= '2025-01-01' AND create_time < '2025-01-02'。 - 隐式类型转换：
phone是 varchar，SQL 里写WHERE phone = 13800000000（数字），索引失效。 - OR 连接非索引列：
WHERE a = 1 OR c = 2，c 没索引，整个走全表。 !=/NOT IN/IS NOT NULL：优化器经常放弃索引。- 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。
五、踩坑清单
- 只信 EXPLAIN 的 rows，不看实际执行时间——估算值可能差 10 倍。
- 加完索引没 ANALYZE TABLE，统计信息没更新，优化器还是走老路。
- 生产直接 ALTER TABLE 加索引，8000 万行的表锁了 40 分钟——应该用 Online DDL 或 gh-ost。
- 把
EXPLAIN里的 type=index 当成「走了索引」，其实是全索引扫描，比全表扫还慢。 - 只优化单条 SQL，不看 QPS 高的短查询——单条 5ms × 1 万 QPS = 每 50ms 一个慢查询，加起来才是真凶。
总结
顺序不能乱：先 EXPLAIN 定位，再判断是索引还是写法，最后才动手。加索引前问自己三个问题：选择性够吗？顺序对吗？写放大能接受吗？
38赞
7收藏
21评论
80浏览