EXPLAIN显示Using filesort说明MySQL未用索引排序，必须额外内存或磁盘排序，是数据量过万即卡顿的硬伤；根本原因是索引结构与查询模式不匹配，包括WHERE未满足最左前缀、ORDER BY含函数、范围条件截断索引有序性、升降序不一致等。
EXPLAIN 显示 Using filesort，说明 MySQL 没法用索引完成排序，必须额外做一次内存或磁盘排序——这不是“可能慢”，是数据量一过万就明显卡顿的硬伤。
为什么加了索引还是出现 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'）后，索引中其后的字段无法参与排序
EXPLAIN 里 key 有值但仍有 Using filesort 怎么办
这说明索引被用于查找（key 列显示索引名），但没用于排序（Extra 仍有 Using filesort）。优先排查以下三点：
- 确认
WHERE条件是否满足最左前缀：比如索引是(status, created_at)，但查询写WHERE created_at > '2024-01-01'，status没出现在WHERE中，排序就断了 - 检查
ORDER BY字段是否连续接在WHERE等值字段之后：索引(a, b, c)支持WHERE a = 1 ORDER BY b, c，但不支持WHERE a = 1 ORDER BY c（跳过了b） - 验证升降序一致性：MySQL 8.0+ 支持
INDEX (status, created_at DESC)，但 5.7 及以前所有字段默认同向，建(status, created_at)配ORDER BY status ASC, created_at DESC依然会Using filesort
如何让 ORDER BY 真正走索引
核心原则是：复合索引要按「过滤字段 + 排序字段」顺序创建，中间不能断、不能跳、不能混方向：
- 慢查询示例：
SELECT id, name, created_at FROM users WHERE status = 'active' ORDER BY created_at DESC LIMIT 20 - 错误建法：
INDEX (created_at)→WHERE条件没覆盖；INDEX (status)→ 排序字段没包含 - 正确建法：
INDEX (status, created_at)→ ✅ 过滤 + 排序都命中 - 进阶优化：如果只查这三列，可扩展为
INDEX (status, created_at, id, name)（注意顺序），避免回表，但前提是先让排序走索引
最容易被忽略的一点：当 ORDER BY 包含多个字段（如 a ASC, b DESC），而你建的是 INDEX (a, b)，在 MySQL 5.7 及以前一定触发 Using filesort——不是索引没建，是索引方向没对齐。
