mysql无法利用索引有序性完成排序时会触发filesort，导致性能陡降；必须确保索引列顺序与where等值条件及order by字段严格匹配，且避免范围查询、函数、混合升降序等破坏索引连续性的操作。
MySQL 能避免文件排序（filesort），但前提是索引结构与查询逻辑严格匹配；一旦 WHERE 或 ORDER BY 中出现范围条件、函数、混合升降序或字段顺序错位，优化器大概率放弃索引排序，直接走 filesort。
为什么 EXPLAIN 显示 Using filesort 就该警惕
这表示 MySQL 没法利用索引的物理有序性完成排序，而是把满足 WHERE 的行先捞出来，再在内存或磁盘里额外排序。性能拐点往往出现在几百行之后——尤其当 sort_buffer_size 不够时，会触发磁盘临时文件，I/O 开销陡增。
-
EXPLAIN中type是ALL或index，且Extra含Using filesort，基本可确认排序未走索引 - 即使有索引，若
ORDER BY字段不在索引最右连续位置（如索引是(a, b, c)，却写ORDER BY b, c），也会失效 -
WHERE a > 10 ORDER BY b DESC这类“范围 + 排序”组合，传统复合索引(a, b)无法避免 filesort —— 因为a的范围扫描已破坏索引中b的局部有序性
索引顺序必须同时满足 WHERE 和 ORDER BY 的访问路径
优化器不是按“先过滤再排序”线性思考的，它依赖单个 B+ 树索引一次性完成定位 + 有序读取。所以索引列顺序本质是定义数据物理排列方式。
- 等值条件优先：如
WHERE status = 1 AND city = 'Beijing' ORDER BY create_time DESC，索引应建为(status, city, create_time) - 范围条件后不能接排序字段：
WHERE age > 25 ORDER BY name用(age, name)索引仍会 filesort；此时可尝试反向设计索引(name, age)，并改写查询为WHERE name > '' AND age > 25 ORDER BY name（需业务逻辑允许） - MySQL 8.0+ 支持降序索引，可显式声明
CREATE INDEX idx_status_time ON orders(status, create_time DESC)，解决ASC/DESC混合问题；5.7 及更早版本只能靠一致方向
覆盖索引能减少回表，但不解决 filesort 本身
覆盖索引（即 SELECT 所有字段都在索引中）能避免回主键聚簇索引查数据，但它只是“让 filesort 更快”，而非“消除 filesort”。真正消除的关键仍是排序字段是否被索引天然有序支持。
- 例如
SELECT id, name FROM users WHERE city = 'Shanghai' ORDER BY create_time，建(city, create_time, id, name)是覆盖索引，但如果create_time不在索引最右连续段，依然会 filesort - 不要为了覆盖而牺牲排序有效性：宁可少几个字段，也要确保
ORDER BY字段紧贴 WHERE 等值字段右侧 - 联合索引总长度不宜过长，尤其含 TEXT/VARCHAR( large ) 字段时，可能拖慢索引树遍历速度
用 EXPLAIN 验证，而不是凭经验猜
同一个 SQL，在不同数据分布、MySQL 版本、统计信息下，优化器选择可能完全不同。必须对每个关键查询跑 EXPLAIN FORMAT=TREE（8.0+）或至少 EXPLAIN 看 type 和 Extra。
- 重点盯住
key列是否命中预期索引，rows是否明显偏大，Extra是否出现Using filesort或Using temporary - 测试时用
SQL_NO_CACHE避免查询缓存干扰，数据量要接近线上规模（百行看不出问题，十万行才暴露） - 注意隐式类型转换：比如
WHERE user_id = '123'（字符串）对比 INT 字段，可能导致索引失效，连带影响后续排序
最易被忽略的一点：索引不是建了就生效，而是取决于查询写法与优化器能否识别出“索引扫描即有序输出”这一路径。哪怕只差一个函数包装（如 ORDER BY DATE(created_at)）、一个 ASC/DESC 不一致、或一个看似无害的 OR 条件，都可能让整个排序逻辑退回 filesort。验证永远比假设可靠。
