加了索引仍出现Using filesort，是因为MySQL必须用同一索引一次性完成过滤和排序；若WHERE条件未对齐索引结构（如等值→范围→排序字段顺序错乱、跳过中间列、多字段排序方向不一致）、SELECT含非索引字段或ORDER BY字段来自非驱动表，则索引无法支撑排序，触发filesort。
为什么加了索引 still 出现 Using filesort
不是索引没建，而是 MySQL 无法用它一次性完成「过滤 + 排序」。优化器会放弃一个只能过滤不能排序的索引，宁可走主键全扫再排序。
常见错觉是给 ORDER BY created_at 单独建 INDEX (created_at) 就行——但只要 WHERE status = 1 存在，这个单列索引大概率被跳过，因为无法同时满足定位和排序。
-
WHERE a > 1 ORDER BY b：索引(a, b)中b在范围查询后已无全局有序性 -
WHERE b = 1 ORDER BY a：b不是最左字段，无法定位起始位置 -
WHERE a = 1 ORDER BY c：索引(a, b, c)跳过中间列b，c失效 -
ORDER BY a ASC, b DESC：MySQL 5.7 及以前完全不认混合方向，建了等于白建
复合索引字段顺序怎么排才真正生效
顺序不是按“哪个字段更重要”，而是严格按执行路径：等值过滤 → 范围过滤 → 排序字段，连续、不可跳。
例如这条查询：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是排序字段，放在最后，B+ 树叶子节点天然倒序可直接扫描 - 若写成
INDEX (status, created_at, age)，created_at会在age值变化时被打断有序性，排序失效
SELECT * 或非索引字段会让覆盖失败
即使索引结构完全匹配 WHERE 和 ORDER BY，只要 SELECT 包含未被索引覆盖的字段（比如 SELECT * 或 SELECT content），MySQL 就必须回表查聚簇索引——而回表后的数据天然无序，Using filesort 不会消失。
- 改写为只选索引已有字段：
SELECT id, name, created_at FROM users WHERE status = 1 ORDER BY created_at DESC - 或扩展索引变成覆盖索引：
INDEX (status, created_at, id, name) - 别重复加
id：主键已隐含在二级索引末尾，单独加反而浪费空间 - 注意：如果业务真需要
content，那就得把content加进索引末尾，但要权衡索引体积与写入开销
EXPLAIN 显示用了索引但仍有 Using filesort 怎么办
说明索引被用于查找（key 列有值），但没用于排序（Extra 仍有 Using filesort）。优先排查这三点：
- 执行
ANALYZE TABLE users更新统计信息——优化器可能因行数预估偏差而误判成本，放弃你的索引 - 检查
ORDER BY是否用了函数或表达式，比如ORDER BY DATE(created_at)，索引字段被包装后无法走索引 - 确认是否多表 JOIN：若
ORDER BY t2.c2，而驱动表是t1，那t2.c2的索引根本不会参与排序路径
最容易被忽略的是统计信息过期和 JOIN 驱动表选择——这两点不会报错，但会让精心设计的索引彻底失效。
