加了索引仍出现Using filesort，是因为MySQL必须用同一索引一次性完成过滤和排序；若WHERE条件未对齐索引结构（如等值→范围→排序字段顺序错乱、跳过中间列、多字段排序方向不一致），或SELECT未覆盖所有返回字段，或ORDER BY字段来自非驱动表，则索引无法支撑排序，触发filesort。
为什么加了索引还是出现Using filesort
不是“建了索引就自动生效”，而是MySQL必须能用该索引一次性完成「过滤 + 排序」。常见错觉是：给ORDER BY字段单独建索引（比如只建INDEX (created_at)）就能避免Using filesort，但实际中只要WHERE条件没对齐索引结构，这个索引大概率被忽略——优化器宁可走主键扫描再排序，也不愿用一个只能过滤不能排序的索引。
典型失效场景包括：
-
WHERE a > 1 ORDER BY b：a是范围条件，索引(a, b)中b已失去全局有序性 -
WHERE b = 1 ORDER BY a：b不是索引最左字段，无法定位起始位置 -
WHERE a = 1 ORDER BY c：跳过索引中间字段b，(a, b, c)对c无效 -
ORDER BY a ASC, b DESC：MySQL 5.7 及以前不支持混合方向，索引(a, b)全为ASC时仍会filesort
组合索引字段顺序怎么排才真正有效
核心原则：**WHERE等值字段 → WHERE范围字段 → ORDER BY字段**，严格连续、不可跳跃。顺序错了，索引就只发挥一半作用。
例如这条查询：
SELECT id, name FROM users WHERE status = 1 AND age BETWEEN 18 AND 30 ORDER BY created_at DESC;
正确索引是：INDEX (status, age, created_at)。注意：
-
status是等值，放最左；age是范围，紧随其后；created_at是排序字段，放在最后——这样MySQL能先定位status = 1的数据块，再在该块内按age范围截取，最后直接倒序读取created_at，无需额外排序 - 如果写成
INDEX (status, created_at, age)，则age范围条件会让created_at失效，因为B+树中created_at的有序性在age值变化时被打破 - 如果
ORDER BY含多字段（如ORDER BY a, b），索引必须是(a, b)，不能是(b, a)；且方向要一致（MySQL 8.0+才支持(a ASC, b DESC)）
SELECT * 或非索引字段会导致覆盖失败
即使索引结构完全匹配WHERE和ORDER BY，只要SELECT里包含未被索引覆盖的字段（比如SELECT *或SELECT content而索引没包含content），MySQL就必须回表查完整行——而回表后的数据天然无序，排序动作仍会发生，Using filesort不会消失。
解决办法只有两个：
- 改写查询，只选索引中已有的字段（覆盖索引）：
SELECT id, name, created_at FROM users WHERE ... ORDER BY created_at - 把高频返回字段加进索引末尾（代价是索引体积变大）：
INDEX (status, created_at, name, id)——但注意id如果是主键，InnoDB二级索引自带主键值，无需重复添加
别迷信“加字段越多越保险”：冗余字段会拖慢写入、占用更多Buffer Pool，且对排序无实质帮助。
多表JOIN时ORDER BY字段来自被驱动表怎么办
这是最容易踩坑的点：哪怕orders.total自己有索引，只要它出现在JOIN后的ORDER BY里，而orders不是驱动表，MySQL就**根本不考虑用它的索引做排序**。执行计划里Using filesort几乎是必然的。
可行路径只有两条：
-
延迟关联（Deferred Join）：先用驱动表主键完成排序，再回表补全。例如：
SELECT u.*, o.total FROM users u JOIN (SELECT user_id FROM orders WHERE ... ORDER BY total DESC LIMIT 20) o_tmp ON u.id = o_tmp.user_id JOIN orders o ON o.user_id = o_tmp.user_id;
-
强制驱动表 + 覆盖索引：用
STRAIGHT_JOIN固定users为驱动表，并在users上建INDEX (status, id)，让排序逻辑落在users.id上（前提是业务允许按用户ID而非订单金额排序）
试图在被驱动表字段上“硬加索引”或“改写WHERE条件”基本无效——MySQL的排序路径只信任驱动表的索引顺序。
