MySQL 慢查询治理实战：从 EXPLAIN 到联合索引优化

MySQL 慢查询排查时，最容易犯的错误是直接“加一个索引试试”。有时索引加了，查询还是慢；有时单列索引很多，优化器却不选；还有时 WHERE 能走索引，但 ORDER BY 仍然触发额外排序。

本文用一个订单列表查询案例，完整演示如何用 EXPLAIN 定位问题，再根据 WHERE、ORDER BY 和 LIMIT 分页设计联合索引。目标不是记住所有字段，而是能从执行计划里判断慢在哪里，改哪里最有效。

摘要

慢查询优化要先看证据：慢日志确认耗时和扫描行数，EXPLAIN 判断访问类型、命中索引、预估扫描行数和额外操作。联合索引设计时，要让高选择性过滤字段在前，范围条件之后的列利用会变弱，排序列要尽量和索引顺序保持一致。

适合人群

适合正在维护 MySQL 业务库、订单列表、后台筛选页、分页查询和报表查询的开发者。示例使用常见订单表，适用于 MySQL 5.7 和 8.0 的大多数业务场景。

目录

1. 先用慢日志确认问题
2. 读懂 EXPLAIN 的关键字段
3. 为什么单列索引不一定够用
4. 联合索引顺序怎么设计
5. 分页查询的两个优化点
6. 常见坑和排查清单

一、先用慢日志确认问题

假设后台有一个订单列表，按状态筛选，并按创建时间倒序分页：

SELECT id, user_id, status, amount, create_time
FROM orders
WHERE status = 2
  AND create_time >= '2026-06-01 00:00:00'
ORDER BY create_time DESC
LIMIT 20;

慢日志里看到扫描行数很大，返回行数却只有 20，这说明数据库读了大量无效数据：

Query_time: 2.351s
Rows_sent: 20
Rows_examined: 982345

这时不要急着加索引，先看执行计划。

二、读懂 EXPLAIN 的关键字段

对上面的 SQL 做分析：

EXPLAIN
SELECT id, user_id, status, amount, create_time
FROM orders
WHERE status = 2
  AND create_time >= '2026-06-01 00:00:00'
ORDER BY create_time DESC
LIMIT 20;

优先关注这几个字段：

• type：访问类型，常见从好到差大致是 const、ref、range、index、ALL；
• possible_keys：可能用到的索引；
• key：实际命中的索引，为 NULL 通常要警惕；
• rows：预估扫描行数，越大越可能慢；
• Extra：额外信息，比如 Using filesort、Using temporary、Using index。

如果看到 type=ALL、key=NULL、rows 很大，基本可以判断存在全表扫描。如果 Extra 里还有 Using filesort，说明排序也没有很好地利用索引。

三、为什么单列索引不一定够用

很多表会分别给 status 和 create_time 加索引：

CREATE INDEX idx_status ON orders(status);
CREATE INDEX idx_create_time ON orders(create_time);

但这个查询同时有状态过滤和时间排序。单列索引可能只能解决一部分问题：用 status 过滤后还要排序，用 create_time 排序后又要过滤大量状态不匹配的行。对这种固定查询模式，更适合联合索引。

四、联合索引顺序怎么设计

针对示例 SQL，可以考虑：

CREATE INDEX idx_status_ctime
ON orders(status, create_time DESC);

这样 status 先做等值过滤，create_time 再用于范围扫描和排序。优化后再看 EXPLAIN，如果 key 命中 idx_status_ctime，rows 明显下降，说明方向是对的。

如果查询还需要返回 id、user_id、amount，并且对回表成本很敏感，可以评估覆盖索引：

CREATE INDEX idx_status_ctime_cover
ON orders(status, create_time DESC, id, user_id, amount);

覆盖索引不是越长越好。索引越长，写入成本和磁盘占用越高。只有高频、延迟敏感、返回列稳定的查询，才值得考虑覆盖索引。

五、分页查询的两个优化点

1. 避免过深 OFFSET

LIMIT 100000, 20 这种深分页会先跳过大量记录，再返回 20 条。数据量越大越慢。更推荐使用游标分页：

SELECT id, user_id, status, amount, create_time
FROM orders
WHERE status = 2
  AND (create_time, id) 

对应索引可以设计为：

CREATE INDEX idx_status_ctime_id
ON orders(status, create_time DESC, id DESC);

2. 排序字段要和索引方向一致

如果查询是 ORDER BY create_time DESC, id DESC，索引顺序也尽量保持一致。混合方向或中间插入范围条件，都可能让排序无法完全利用索引。

六、常见坑和排查清单

1. 只看 key，不看 rows

命中索引不代表性能一定好。如果 rows 仍然很大，说明索引选择性不足，可能需要调整联合索引顺序，或者重新评估查询条件。

2. 低选择性字段放在最前面

如果 status 只有 0、1、2 三个值，而 user_id 区分度很高，那么面向用户订单列表时，(user_id, status, create_time) 往往比 (status, user_id, create_time) 更适合。

3. 为每个条件都建单列索引

索引不是越多越好。大量单列索引会增加写入成本，也不一定能满足组合过滤和排序。应该围绕高频查询模式设计联合索引。

4. 忽略线上数据分布

测试库几千行数据看不出问题，线上几百万行就会明显变慢。优化前后都要看真实量级下的慢日志、扫描行数和响应时间。

七、总结

MySQL 慢查询治理要按顺序来：先用慢日志确认问题，再用 EXPLAIN 定位访问方式和扫描行数，最后根据查询模式设计联合索引。对订单列表这类筛选加排序加分页的场景，重点是索引列顺序、排序方向、覆盖索引取舍和深分页优化。只要证据链清楚，SQL 优化就不会变成盲目试错。