ORDER BY 字段不走索引且出现 Using filesort 通常是因为索引列顺序与排序字段不一致，或 WHERE 条件中存在范围查询中断了索引有序性。优化核心是调整复合索引顺序或消除范围查询，风险在于索引变更可能影响其他查询场景。

命令速用版

直接通过 EXPLAIN 分析 SQL 执行计划，定位是否触发文件排序。

EXPLAIN SELECT * FROM table_name WHERE col1 = 1 ORDER BY col2;

观察输出结果中 Extra 字段的值，若包含 Using filesort 则说明未走索引排序。

为什么会这样

索引本身是有序结构，但只有当查询条件利用了索引的有序性时，MySQL 才能直接按索引顺序读取数据。

如果 ORDER BY 字段不在索引中，或者索引字段顺序与 ORDER BY 不一致，MySQL 无法利用索引的有序性，必须将数据取出后在内存或磁盘中进行排序，即 filesort。此外，如果 WHERE 条件中对索引列使用了范围查询（如 >、<），索引在该列之后的有序性会失效，后续字段的 ORDER BY 也无法使用索引。

分步处理

按照检查执行计划、调整索引结构、回归测试的顺序进行优化。

步骤 1：确认当前执行计划

执行 EXPLAIN 命令，记录 type、key 和 Extra 字段信息。

步骤 2：分析索引匹配度

检查现有索引是否包含 ORDER BY 字段。如果是复合索引，确认 WHERE 条件字段是否位于索引最左侧，且 ORDER BY 字段紧随其后。

步骤 3：调整索引

创建新的复合索引，例如 ALTER TABLE table_name ADD INDEX idx_col1_col2 (col1, col2);，确保 col1 用于 WHERE 过滤，col2 用于 ORDER BY 排序。

步骤 4：回滚提醒

修改索引前记录原有索引名称，若新索引导致其他慢查询，可通过 DROP INDEX 快速恢复。

怎么验证是否生效

再次执行相同的 EXPLAIN 命令，对比 Extra 字段变化。

若 Extra 字段中 Using filesort 消失，且 key 字段显示为新建立的索引名称，说明优化生效。同时观察 rows 扫描行数是否减少，确认查询效率提升。

常见坑

某些场景下即使建立索引也无法避免 filesort，需提前识别。

• 混合排序方向：MySQL 8.0 之前不支持索引同时用于 ASC 和 DESC 混合排序，会导致 filesort。
• 函数处理：对 ORDER BY 字段使用函数（如 DATE(create_time)）会导致索引失效，必须使用原始字段。
• 多表连接：JOIN 查询中 ORDER BY 字段来自非驱动表且无关联索引时，极易触发 filesort。

常见问题

filesort 一定会导致性能问题吗

不一定，小数据量下内存排序速度很快，只有数据量大且未走索引时才需优化。

加了 LIMIT 能避免 filesort 吗

不能直接避免，但能减少排序数据量，降低 filesort 带来的开销。

为什么复合索引顺序不能随意调整

复合索引遵循最左前缀原则，顺序改变会导致 WHERE 条件无法匹配索引左侧，进而影响排序可用性。