MySQL一加ORDER BY就出现Using filesort，是因为其仅能在索引叶子节点物理顺序与查询排序需求完全匹配时跳过排序；否则必须回表后在内存或磁盘中额外排序。根本原因包括：ORDER BY字段未命中索引最左前缀、范围查询中断有序性、混合ASC/DESC未显式建索引、函数/表达式破坏索引匹配、SELECT *导致回表丢失顺序、多表JOIN中排序字段来自被驱动表，以及大LIMIT偏移加剧磁盘排序。
MySQL 为什么一加 ORDER BY 就出现 Using filesort？
因为 MySQL 只有在能“顺着索引叶子节点顺序读取数据”时，才跳过排序步骤；一旦 ORDER BY 字段不在索引覆盖范围内，或顺序/方向不匹配，它就无法利用 B+ 树的物理有序性，只能把符合条件的行全捞出来，在内存或磁盘里重新排——这就是 Using filesort 的本质。
常见错误现象：
- 加了
WHERE a = ?很快，但加上ORDER BY b后执行时间暴涨几倍 -
EXPLAIN输出中key显示用了索引，但Extra仍含Using filesort - 建了单列索引
(b)，但查询是WHERE a = ? ORDER BY b，依然慢
复合索引字段顺序怎么排才让 WHERE + ORDER BY 都走索引？
不是“有索引就行”，而是要满足最左前缀 + 连续匹配 + 排序需求。关键在于：等值条件字段必须在前，范围条件字段（如 >, BETWEEN）之后的字段，索引就“断”了，ORDER BY 无法再复用。
- 查询
WHERE status = 1 AND created_at > '2024-01-01' ORDER BY updated_at→ 索引应为(status, created_at, updated_at)，不能是(status, updated_at, created_at) - 查询
WHERE user_id = 100 ORDER BY create_time DESC→ 索引(user_id, create_time)有效；若建的是(create_time)单列索引，则WHERE和ORDER BY无法同时受益 - MySQL 8.0+ 支持混合方向索引，但需显式声明：
INDEX (x ASC, y DESC)；5.7 或更早版本建议统一用ASC，否则可能不走索引
哪些 ORDER BY 写法注定无法用索引加速？
这类情况即使建了索引，优化器也会直接放弃，因为索引里存的是原始值，没法直接比较函数结果或跨列表达式。
-
ORDER BY UPPER(name)、ORDER BY created_at + INTERVAL 1 DAY→ 函数/表达式导致索引失效 -
ORDER BY ABS(score)、ORDER BY CONCAT(first, last)→ 计算逻辑无法下推到索引扫描层 -
ORDER BY t1.id, t2.name（多表 JOIN 后跨表排序）→ 若t2.name不在驱动表索引中，大概率触发Using temporary; Using filesort - 字符集或 collation 不一致的列参与排序（如
utf8mb4_0900_as_csvsutf8mb4_general_ci）→ 隐式转换使索引不可用
sort_buffer_size 调大真能解决问题吗？
不能治本，只缓解症状。这个参数控制单个查询可用的内存排序空间，但它是每个连接独占的，设太大容易引发内存争抢；而且只要没走索引，哪怕全在内存排，复杂度仍是 O(n log n)，数据量一上去就卡住。
- 查
SHOW STATUS LIKE 'Sort_merge_passes';，数值持续上升说明频繁落盘排序 - 临时调高
sort_buffer_size（比如从默认 2MB 到 4MB）可观察是否改善，但别当成常规手段 - 真正有效的解法永远是：让排序发生在索引扫描过程中，而不是扫描完再排
最容易被忽略的一点：即使索引字段顺序对了，如果 SELECT * 导致大量回表，或者 LIMIT 偏移量极大（如 LIMIT 1000000, 20），性能照样崩——这时候得结合覆盖索引或游标分页来补救。
