Using filesort表示MySQL无法利用索引天然有序性完成排序，必须额外执行内存或磁盘排序；它出现在EXPLAIN的Extra字段中，是优化器因索引不匹配ORDER BY需求而做出的“无奈声明”，常见于ORDER BY字段不在索引最左前缀、混合ASC/DESC、使用函数表达式、JOIN中对非驱动表排序等场景。
Navicat执行计划里出现Using filesort意味着什么
using filesort不是错误，而是mysql在explain的extra字段中告诉你：“我没法直接按索引顺序返回你要的排序结果，得额外跑一趟排序逻辑”。它不等于一定写磁盘——只要待排序数据量 ≤ sort_buffer_size（默认通常256kb），就纯走内存；超了才会落盘生成临时文件（如/tmp/my****），这时才真正拖慢查询。
常见错觉是“有索引就不会Using filesort”，其实不然。比如索引是(a, b)，但你写ORDER BY b，或ORDER BY a ASC, b DESC（MySQL 5.7及更早不支持降序索引），或ORDER BY UPPER(name)，都会触发它。
哪些ORDER BY写法大概率触发Using filesort
以下情况即使建了索引，优化器也大概率放弃用索引排序：
-
ORDER BY字段不在索引最左连续位置，例如索引(status, created_at)，却写ORDER BY created_at（跳过了status） - 混合排序方向，如
ORDER BY a DESC, b ASC，而索引是(a, b)（MySQL 8.0+ 支持(a DESC, b ASC)显式定义，老版本不认） - 对字段用了函数或表达式：
ORDER BY DATE(created_at)、ORDER BY id + 1、ORDER BY CONCAT(first_name, ' ', last_name) -
JOIN中对非驱动表字段排序，例如SELECT u.* FROM users u JOIN orders o ON u.id = o.user_id ORDER BY o.created_at（o是被驱动表，它的created_at索引无法参与外层排序） - 使用
UNION后整体ORDER BY，子查询各自优化，外层排序无法复用任一子句索引
怎么建索引才能让Using filesort消失
核心是让索引的物理顺序 ≡ WHERE筛选顺序 + ORDER BY逻辑顺序。建索引时注意三点：
-
WHERE中的等值条件（=、IN）必须放最左，且连续。例如WHERE status = 'active' AND type IN ('A','B')→ 索引开头必须是(status, type) - 排序字段紧接其后，不能跳过中间字段。比如索引
(a, c)无法支撑WHERE a = 1 ORDER BY c，因为缺失b导致范围断裂 - 如果
SELECT只查索引字段（如SELECT id, name FROM t WHERE status='X' ORDER BY created_at），可加覆盖索引(status, created_at, id, name)，避免回表，也更容易消除Using filesort
示例：查询SELECT * FROM user WHERE status = 1 ORDER BY created_at DESC LIMIT 20，最优索引是INDEX (status, created_at)（MySQL 5.7兼容）或INDEX (status, created_at DESC)（MySQL 8.0+ 更准确）。
为什么加了索引还是看到Using filesort
索引存在 ≠ 被用于排序。以下情况会强制回退到文件排序：
- 索引字段类型与
ORDER BY表达式不一致，比如索引是INT，但写了ORDER BY CAST(id AS CHAR) -
WHERE用了范围查询（>、BETWEEN、LIKE 'abc%'），导致后续索引字段无法用于排序。例如索引(a, b, c)，查询WHERE a > 1 ORDER BY b, c，a之后的字段失效 - 查询含
SELECT *且索引未覆盖所有字段，MySQL可能选择全表扫描+排序，而非回表代价高的索引扫描 -
possible_keys有值但key为空，说明优化器认为走索引成本更高（比如高基数字段上低选择率的WHERE），此时需用FORCE INDEX或重写查询验证
真正容易被忽略的是：索引顺序必须严格匹配查询模式，哪怕只是多一个IN或少一个等值条件，都可能让排序能力归零。别只看“有没有索引”，要看“这个索引能不能在这条语句里把排序活干完”。
