Using filesort 表示 MySQL 无法利用索引有序性而需额外排序，主因是 ORDER BY 字段未按索引最左前缀、方向不匹配、范围查询后字段失效或未覆盖索引等。
为什么 ORDER BY 会触发 Using filesort
MySQL 在执行 ORDER BY 时，如果无法利用索引直接按序读取数据，就会把结果集拉出来再内存或磁盘排序——这个过程就叫 Using filesort。它不是“用了文件排序”这么简单，而是意味着：没走索引排序路径，丢了索引的天然有序性。
常见诱因包括：
-
ORDER BY字段不在索引最左前缀上（比如索引是(a, b)，却只按b排序） - 混合 ASC/DESC（如
ORDER BY a ASC, b DESC），而索引定义不匹配 - 查询中用了
SELECT *或包含非索引字段，导致无法走覆盖索引，被迫回表后排序 - WHERE 条件和 ORDER BY 字段没对齐索引结构（比如 WHERE 用
a = ?，ORDER BY 用c，但索引是(a, b)）
复合索引怎么建才真正覆盖 ORDER BY
关键不是“加个索引”，而是让索引结构和查询模式严格对齐。顺序必须满足：先过滤字段（WHERE），再排序字段（ORDER BY），且中间不能断层。
假设查询是：
SELECT id, name FROM users WHERE status = 1 ORDER BY created_at DESC;
正确索引应为：INDEX (status, created_at) —— 因为 status 是等值条件，created_at 是单方向排序，MySQL 可以直接按索引倒序扫描。
注意几个硬约束：
- 如果
ORDER BY含多个字段，比如ORDER BY a ASC, b DESC，MySQL 8.0+ 才支持在单个索引里混合方向（INDEX (a ASC, b DESC)），5.7 及以前只能全 ASC 或全 DESC - WHERE 中出现的范围条件（如
created_at > '2023-01-01'）之后的字段，无法用于索引排序。所以INDEX (status, created_at, name)中，若WHERE status = 1 AND created_at > '2023-01-01'，则name就不能再参与排序优化 - 避免冗余字段：索引
(status, created_at, id)比(status, created_at)多占空间，除非id是为了覆盖SELECT id避免回表
EXPLAIN 里看到 Using filesort 但索引明明存在？
索引存在 ≠ 被选用。MySQL 优化器可能因为统计信息过期、行数预估偏差或成本判断，放弃使用你建的索引。
排查步骤：
- 用
EXPLAIN FORMAT=JSON查看used_key_parts和using_filesort是否同时为true；如果是，说明索引被用了但没覆盖排序 - 检查
rows预估值是否远大于实际，执行ANALYZE TABLE users更新统计信息 - 强制指定索引测试：
SELECT ... FROM users USE INDEX (idx_status_created) WHERE ... ORDER BY ...，看EXPLAIN是否消失Using filesort - 确认字符集/排序规则一致：比如字段是
utf8mb4_0900_as_cs，但索引隐式用了utf8mb4_general_ci，会导致索引失效
覆盖索引 + ORDER BY 的边界在哪
覆盖索引能消除回表，但不能绕过排序逻辑本身。只有当索引顺序与 ORDER BY 完全一致时，才能跳过 filesort。
典型误区：
- 以为
SELECT id FROM t WHERE a = 1 ORDER BY b加了INDEX (a, b, id)就够了——其实只要id在最后，它不影响排序能力，关键还是(a, b)结构是否匹配 - 在
WHERE里用了函数，比如WHERE DATE(created_at) = '2024-01-01'，哪怕有created_at索引，也无法走索引排序 - 联合索引中插入了
IS NULL或IN这类非连续条件，会让后续字段退出排序链
最易被忽略的一点：时间字段的精度。如果 created_at 是 DATETIME(6)，而你建索引时没留意隐式截断，或者查询里用了 CAST(created_at AS DATETIME)，都会断掉索引排序能力。
