如何优化MySQL OrderBy排序导致的UsingFilesort_利用索引的有序性消除文件排序-mysql教程-PHP中文网

using filesort 表示排序未走索引，是数据量过万即明显卡顿的硬伤；根本原因是索引结构与查询模式不匹配，如复合索引未满足最左前缀、order by 含函数、where 用范围条件或升降序不一致等。

如何优化mysql orderby排序导致的usingfilesort_利用索引的有序性消除文件排序

EXPLAIN 出现 Using filesort 就代表排序没走索引，不是“可能慢”，是数据量一过万就明显卡顿的硬伤——必须让索引结构和查询模式严格对齐，否则加了索引也白加。

为什么加了索引还是出现 `Using filesort`

常见误判是“ORDER BY 字段有索引就行”。实际 MySQL 只能利用索引的最左前缀做排序，且要求字段顺序、升降序、WHERE 条件三者完全匹配：

WHERE 中用了非最左字段（如索引是 (a, b, c)，却写 WHERE b = 1），该索引无法用于排序
ORDER BY 含函数或表达式（ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY），索引值 ≠ 计算值，直接失效
MySQL 5.7 及以前不支持混合 ASC/DESC：索引定义为 (user_id, created_at)，但查询写 ORDER BY user_id ASC, created_at DESC，仍触发 Using filesort
WHERE 中存在范围条件（created_at > '2023-01-01'）后，索引中其后的字段无法参与排序

怎么建复合索引才真正覆盖 `ORDER BY`

核心是「过滤字段 + 排序字段」连续排列，中间不能断层。例如查询：

SELECT id, order_no FROM orders WHERE shop_id = 1001 AND status = 'paid' ORDER BY created_at DESC LIMIT 10;

最优索引是：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

INDEX (shop_id, status, created_at DESC)

shop_id 和 status 是等值条件，放最前；created_at 是排序字段，紧接其后
created_at DESC 必须显式声明（MySQL 8.0+ 才认；5.7 建了也无效，会按升序存）
若还想避免回表，可扩展为覆盖索引：INDEX (shop_id, status, created_at DESC, id, order_no)
反例：INDEX (created_at, shop_id) 或 INDEX (status, shop_id, created_at) 都无法命中

多表 JOIN 后 `ORDER BY` 字段来自被驱动表怎么办

MySQL 默认只对驱动表（FROM 后第一张表）的 ORDER BY 字段尝试索引排序。一旦排序字段来自被驱动表（如 JOIN orders ON u.id = o.user_id ORDER BY o.total DESC），即使 orders 表上有 total 索引，也基本必出 Using filesort。

别指望在被驱动表上单独建索引解决这个问题
可行路径只有两条：一是改用延迟关联（Deferred Join），先用子查询拿到排序后的主键，再回表补字段；二是把被驱动表的关键排序字段“拉”进驱动表索引（仅当 JOIN 条件强关联、且能预估取值范围时可行）

典型延迟关联写法：

SELECT u.name, o.total FROM users u
JOIN orders o ON u.id = o.user_id
JOIN (SELECT user_id FROM orders WHERE user_id IN (SELECT id FROM users WHERE country = 'CN') ORDER BY total DESC LIMIT 10) tmp ON u.id = tmp.user_id;