当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL ORDER BY 排序变慢怎么办：从 filesort 到联合索引一步步排查

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

来源：17golang原创 2026-06-15 12:28:04 0浏览收藏

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

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

适合人群

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

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

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

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 排序，接口就慢了。

MySQL ORDER BY 排序变慢的排查流程图，展示慢接口、查看计划、发现 filesort、设计联合索引和耗时下降

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

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

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 条，不再额外排序。

MySQL ORDER BY 联合索引优化流程图，展示筛选字段、排序字段、联合索引、减少扫描和耗时下降

验证结果：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 和接口耗时一起验证。这样排查，比盲目加索引更稳，也更容易解释优化为什么有效。