MySQL ORDER BY 排序变慢怎么办：从 filesort 到联合索引一步步排查

我们先看一个列表接口的现场：订单列表平时几十毫秒返回，活动期间数据量上来后突然变成 1 秒多。业务同学说“只是按创建时间倒序查 20 条”，听起来不复杂，但数据库却越来越慢。

遇到这种问题，不要先急着加缓存。我们先把 SQL、筛选条件、排序字段和执行计划拿出来，看看到底是不是 ORDER BY 没吃到合适的索引，最后走到了额外排序。

适合人群

本文适合正在维护 MySQL 列表查询、分页接口、后台管理搜索页的开发者。你需要了解基本的索引、EXPLAIN、WHERE 和 ORDER BY。

目录

• 问题现场：列表接口排序突然变慢
• 初步判断：先确认慢在排序还是筛选
• 动手验证：用 EXPLAIN 看 Extra
• 定位原因：索引顺序和排序方向没对齐
• 修复方案：按筛选和排序设计联合索引
• 验证结果：rows、Extra 和耗时一起看
• 常见坑位和总结

问题现场：列表接口排序突然变慢

假设订单表结构简化如下：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  user_id BIGINT NOT NULL,
  status TINYINT NOT NULL,
  created_at DATETIME NOT NULL,
  amount DECIMAL(10, 2) NOT NULL
);

接口 SQL 是：

SELECT id, user_id, status, created_at, amount
FROM orders
WHERE user_id = 1001
  AND status = 1
ORDER BY created_at DESC
LIMIT 20;

一开始数据少，这条 SQL 看不出问题。等用户订单多了以后，数据库需要先筛出大量记录，再按 created_at 排序，接口就慢了。

初步判断：先确认慢在排序还是筛选

我们先不要直接创建索引。第一步拆开看：筛选条件是谁，排序字段是谁，返回多少行。

• user_id 是等值筛选。
• status 是等值筛选。
• created_at 是排序字段。
• LIMIT 20 只要前 20 条。

如果索引能按 user_id、status 定位，再顺着 created_at 的顺序取数据，数据库就不需要额外排序。反过来，如果索引只能筛选不能满足排序，就可能出现 Using filesort。

动手验证：用 EXPLAIN 看 Extra

接着看执行计划：

EXPLAIN
SELECT id, user_id, status, created_at, amount
FROM orders
WHERE user_id = 1001
  AND status = 1
ORDER BY created_at DESC
LIMIT 20;

重点看几个字段：

• key：实际使用了哪个索引。
• rows：预计要扫描多少行。
• Extra：是否出现 Using filesort。

如果你看到类似结果：

key: idx_user_id
rows: 25800
Extra: Using where; Using filesort

这一步说明：MySQL 可能先用 user_id 找到一批数据，再按 created_at 做额外排序。数据越多，这个排序成本越明显。

定位原因：索引顺序和排序方向没对齐

现在可以定位到原因：现有索引只覆盖了部分筛选条件，没有把排序字段放进同一条可用路径里。

比如只有下面这个索引：

CREATE INDEX idx_user_id ON orders(user_id);

它能帮我们找到某个用户的订单，但不能保证这些订单已经按 status 和 created_at 的组合顺序排好。于是查询还要继续过滤和排序。

设计索引时要顺着 SQL 的读取路径看：

• 先放等值筛选字段：user_id、status。
• 再放排序字段：created_at。
• 如果分页需要稳定顺序，可以补上 id。

修复方案：按筛选和排序设计联合索引

针对这条 SQL，可以创建这样的联合索引：

CREATE INDEX idx_user_status_created
ON orders(user_id, status, created_at DESC);

如果你的 MySQL 版本或团队规范不使用降序索引，也可以先使用：

CREATE INDEX idx_user_status_created
ON orders(user_id, status, created_at);

很多场景下 MySQL 仍然可以反向扫描索引拿到倒序结果。真正要不要显式写 DESC，要结合版本、SQL 和实际计划确认。

加索引后再看一次计划，理想变化是：

key: idx_user_status_created
rows: 20
Extra: Using where

这说明数据库可以沿着联合索引定位并按顺序取前 20 条，不再额外排序。

验证结果：rows、Extra 和耗时一起看

最后不要只看 SQL 能不能跑，还要看三个信号：

• rows 是否明显下降。
• Extra 是否不再出现 Using filesort。
• 接口耗时是否在真实参数下稳定下降。

可以用同一组用户和状态做前后对比：

优化前：rows 25800，Extra 包含 Using filesort，耗时 1200ms
优化后：rows 20，Extra 不含 Using filesort，耗时 35ms

如果计划变好了但接口仍慢，就继续看是否有回表、网络传输、返回字段过多、连接池等待等其他问题。索引只是这一轮排查的核心，不代表所有慢都来自排序。

常见坑位和总结

1. 只给排序字段单独建索引

如果 SQL 有强筛选条件，单独给 created_at 建索引不一定合适。数据库可能按时间顺序扫很多不属于目标用户的数据，反而不稳。

2. 联合索引字段顺序随便放

等值筛选字段通常放前面，排序字段接在后面。字段顺序要贴近 SQL 的筛选和排序路径。

3. 分页排序没有稳定字段

如果多个订单的 created_at 完全相同，只按时间排序可能导致翻页时顺序抖动。可以考虑在排序里加上 id，并把它纳入索引设计。

4. 只在小数据量上验证

小表里很多问题看不出来。要用接近真实分布的数据验证，尤其是某些用户、店铺或租户的数据量明显更大时。

总结一下，ORDER BY 变慢的排查思路是：先确认筛选字段和排序字段，再用 EXPLAIN 看是否出现 Using filesort，接着按等值筛选加排序字段设计联合索引，最后用 rows、Extra 和接口耗时一起验证。这样排查，比盲目加索引更稳，也更容易解释优化为什么有效。