加了索引仍出现Using filesort，根本原因是索引存在≠被选用：优化器可能因统计信息过期、隐式类型转换或成本误判弃用索引；联合索引顺序必须严格匹配查询逻辑（WHERE等值→ORDER BY→SELECT覆盖字段），且避免范围条件截断、混合排序方向不兼容（5.7前）、非覆盖字段导致回表破坏有序性。
为什么加了索引还是出现Using filesort
索引存在 ≠ 被选用。MySQL优化器可能因统计信息过期、隐式类型转换或成本误判而跳过你的索引。比如 WHERE phone = 13800138000（传入数字）对比 phone VARCHAR(20) 字段，会触发隐式转换，导致索引失效；又或者大批量导入后未执行 ANALYZE TABLE table_name，优化器基于陈旧统计误判全表扫描更“便宜”。用 FORCE INDEX (idx_name) 临时验证：如果加了它之后 Using filesort 消失，说明问题不在索引结构，而在优化器决策逻辑。
联合索引字段顺序必须严格匹配查询逻辑
ORDER BY 字段必须紧接在 WHERE 等值条件字段之后，且不能被范围条件“截断”。例如：
-
WHERE status = 'active' ORDER BY created_at DESC→ 必须建INDEX (status, created_at)，(created_at, status)无效 -
WHERE user_id = 100 AND age > 25 ORDER BY score→INDEX (user_id, age, score)可用，因为age是范围但score仍能被有序访问 -
WHERE user_id > 100 ORDER BY age→age在索引中即使存在，也无法保证全局有序，索引对排序失效
MySQL 8.0+ 支持混合方向索引（如 INDEX (a ASC, b DESC)），但 5.7 及以前版本要求所有排序字段方向一致，否则仅前缀部分生效。
SELECT * 或非覆盖字段会破坏排序索引的利用
即使索引结构完全匹配 WHERE + ORDER BY，只要 SELECT 列表里包含未被索引覆盖的字段（尤其是 *），MySQL 就可能放弃走索引排序路径，转而用文件排序 + 回表。这不是 bug，是优化器权衡：当需要回表取大量数据时，它认为先排序再查行，比按索引顺序逐行回表更高效。解决方法是补全覆盖字段：
- 原查询：
SELECT id, name FROM orders WHERE status = 'shipped' ORDER BY created_at DESC - 对应索引应为：
INDEX (status, created_at, id, name)，字段顺序严格按 WHERE → ORDER BY → SELECT 列表排列 - 避免把
TEXT、BLOB字段塞进索引——它们不支持索引，强行添加会报错或被忽略
Using filesort 不等于慢，但它是性能拐点信号
单次小结果集的 Using filesort 可能只消耗内存 sort_buffer，影响有限；但一旦配合 LIMIT offset, n（尤其 offset 大），MySQL 往往要先排完全部匹配行再截取，CPU 和 IO 开销陡增。此时索引是否消除 Using filesort 就不再是“可选优化”，而是关键瓶颈。最容易被忽略的是：它和 Using temporary 常共存，但二者成因不同——前者主因排序路径不匹配，后者多由 GROUP BY 或去重触发，需分开处理。
