ORDER BY 慢八成因触发 Using filesort；需索引覆盖排序字段且顺序、方向严格匹配B+树有序性，否则即使有索引也会失效——如复合索引(a,b,c)仅支持ORDER BY a、a,b或a,b,c同向排序，WHERE条件非最左前缀或含函数/表达式时同样无法利用索引排序。
ORDER BY 慢，八成是因为触发了 Using filesort；只要让索引覆盖排序字段且顺序匹配，InnoDB 的 B+ 树天然有序性就能直接返回结果，根本不用临时表或内存排序。
为什么加了索引还是出现 Using filesort
常见误区是“只要 ORDER BY 字段有单列索引就行”，其实 InnoDB 要求更严格：
- 复合索引必须满足最左前缀，且字段顺序、升降序（
ASC/DESC）与ORDER BY完全一致 —— 例如索引是INDEX(user_id ASC, created_at DESC)，那ORDER BY user_id, created_at DESC可用；但ORDER BY created_at, user_id或ORDER BY user_id ASC, created_at ASC就不行 - WHERE 条件里用了非最左字段（如索引
(a,b,c)，但查询写WHERE b = 1），该索引无法用于排序 -
ORDER BY中含函数或表达式（ORDER BY UPPER(name)、ORDER BY a + 1）—— 索引值 ≠ 计算值，优化器直接放弃走索引排序 - 多表 JOIN 后对被驱动表字段排序（比如
JOIN orders ON users.id = orders.user_id ORDER BY orders.created_at），InnoDB 通常不复用被驱动表索引做排序
EXPLAIN 里怎么看是否真走了索引排序
关键盯紧 Extra 列，不是看有没有索引，而是看它是否“下推”到了存储层：
-
Using index：排序已由索引完成，最快路径 - 空（无 Extra）：也表示排序走索引，只是没用到覆盖索引的全部字段
-
Using filesort：明确警告：MySQL 正在回表取数据后二次排序，性能瓶颈就在这儿 - 同时出现
Using where; Using filesort：WHERE 走了索引，但排序没走，说明索引设计没兼顾排序需求
注意：rows 值如果接近全表行数，再配合 Using filesort，基本等于全量数据在内存或磁盘上重排。
哪些 ORDER BY 场景注定绕不开 filesort
这些写法 MySQL 根本没法利用索引有序性，优化器会直接跳过索引排序逻辑：
-
ORDER BY RAND()：每次都要随机打乱，无序可言 -
ORDER BY ABS(score)、ORDER BY JSON_EXTRACT(data, '$.name')：函数破坏索引有序性 -
ORDER BY a, b DESC, c ASC（而索引是(a,b,c)全 ASC）：MySQL 5.7 不支持混合方向，8.0+ 才能建INDEX(a ASC, b DESC, c ASC)匹配 -
SELECT * FROM t1 JOIN t2 ON ... ORDER BY t2.x：非驱动表字段排序，优化器通常拒绝用其索引做排序
这类场景要么重构查询逻辑（比如预计算并存字段），要么接受 filesort 并调优 sort_buffer_size 和 max_length_for_sort_data。
用覆盖索引减少回表，顺便加速 ORDER BY
即使排序本身走了索引，如果 SELECT 字段不在索引里，InnoDB 还得根据主键回表捞数据 —— 这个过程在大偏移分页时尤其伤：
- 建联合索引时把常用查询字段一起带上，例如常查
SELECT id, title, status FROM posts WHERE category = ? ORDER BY created_at DESC，那就建INDEX(category, created_at DESC, id, title, status) - 这样
EXPLAIN的Extra会显示Using index，全程只走索引 B+ 树，不碰聚簇索引页 - 但注意：索引越宽，写入开销越大，且可能挤占 Buffer Pool；别把大字段（如
TEXT）塞进索引
真正难处理的是高偏移分页（LIMIT 100000, 20）：即使走了索引，也要跳过前 10 万行主键，I/O 成本仍高。这时候光靠索引不够，得结合游标分页或延迟关联。
