ORDER BY 用覆盖索引避免 Filesort 的关键是让排序字段为索引最右连续部分且顺序一致，并将查询列全部包含在索引中；MySQL 8.0+ 支持混合 ASC/DESC，5.7 及以前遇 DESC 即退化；EXPLAIN 中出现 Using filesort 表示未走索引排序，Using index 表示覆盖索引生效。
ORDER BY 怎么用覆盖索引避免 Filesort
MySQL 在执行 ORDER BY 时，如果排序字段不在索引的最左前缀中，或者索引不能“覆盖”查询所需的所有列，就会触发 Filesort——这不是磁盘文件排序，而是内存/临时文件里的排序操作，性能开销明显。关键不是“有没有索引”，而是“索引能不能让 MySQL 直接按序读出结果”。
实操建议：
- 确保
ORDER BY字段是索引的**最右连续部分**，且顺序一致（如ORDER BY a, b需要索引(a, b)或(x, a, b)，但不能只建(b)） - 如果还带
SELECT *或额外字段，必须把它们也加进索引末尾，构成覆盖索引（例如SELECT id, name FROM t ORDER BY created_at，建索引(created_at, id, name)） - 注意 ASC/DESC 混用：MySQL 8.0+ 支持混合方向索引（如
(a ASC, b DESC)），但 5.7 及更早版本只要有一个DESC就无法用索引做排序，会退回到 Filesort - 用
EXPLAIN看Extra列：出现Using filesort就说明没走索引排序；出现Using index才表示用了覆盖索引
GROUP BY 和 ORDER BY 共存时的索引设计陷阱
当语句里同时有 GROUP BY 和 ORDER BY（尤其是字段相同时），很多人以为建一个索引就能通吃。其实 MySQL 对两者的索引利用逻辑不同：GROUP BY 优先依赖分组字段的有序性来去重聚合，ORDER BY 则依赖最终结果集的输出顺序。两者冲突时，优化器可能放弃索引排序。
实操建议：
- 如果
GROUP BY a ORDER BY a，索引(a)足够；但如果GROUP BY a ORDER BY b，且b不在分组键里，MySQL 无法复用同一个索引完成两件事，大概率触发 Filesort - 聚合后还要排序的场景（比如
SELECT a, COUNT(*) FROM t GROUP BY a ORDER BY COUNT(*) DESC），COUNT(*)是计算值，不可能被索引覆盖，这时无论如何都会 Filesort——别硬扛，考虑物化中间结果或应用层排序 - 避免在
GROUP BY后选非分组字段（如SELECT a, b FROM t GROUP BY a），这在 SQL mode 严格时直接报错，在宽松模式下结果不可控，也破坏索引有效性
覆盖索引失效的典型信号和检查方法
你以为建了 (a, b, c) 就能覆盖 SELECT a,b,c FROM t WHERE a=1 ORDER BY b？不一定。几个隐蔽但高频的失效点会让 MySQL 主动弃用索引排序。
常见错误现象：
-
WHERE条件用了函数或表达式：比如WHERE YEAR(created_at) = 2023，即使created_at有索引，也无法用于后续ORDER BY - 隐式类型转换：
user_id是INT，但查询写成WHERE user_id = '123'，索引仍可用，但排序可能失效（尤其配合ORDER BY时） - 使用了
OR连接多个条件，且各分支涉及不同字段，容易导致索引选择失败或仅用到部分 - 表统计信息过期（
ANALYZE TABLE没跑），优化器误判索引效率，宁可全表扫也不走排序索引
检查方法：强制用索引 + EXPLAIN FORMAT=JSON，重点看 using_filesort 和 using_index 是否同时为 true；再对比 key_len 是否符合预期长度。
GROUP BY 的松散索引扫描 vs 紧凑索引扫描
MySQL 对 GROUP BY 有两种执行策略：松散（Loose）索引扫描能跳着读索引快速聚合，紧凑（Tight）则要先定位再扫描一段。只有满足特定结构的索引才能触发松散扫描——这是真正省性能的关键，但文档极少提。
使用场景与限制：
- 松散扫描要求：索引必须以
GROUP BY字段开头，且**所有分组字段必须连续、最左、无间隙**；例如GROUP BY a, b，索引必须是(a, b, ...)，不能是(a, c, b) - 如果
SELECT里有聚合函数以外的非分组字段（哪怕只是MAX(c)），就退化为紧凑扫描，性能下降明显 - 松散扫描不支持
DISTINCT和HAVING过滤聚合结果——这些逻辑必须在扫描后补上，也就意味着无法跳读 - 用
EXPLAIN看不到“松散”字样，但可通过rows值判断：松散扫描的rows通常远小于表总行数，而紧凑扫描接近全量扫描
覆盖索引不是万能解药，特别是涉及聚合和多字段排序时，MySQL 的索引利用规则比表面看起来更苛刻。最容易被忽略的是：松散索引扫描的触发条件极其严格，稍有偏差就退回低效路径，而 EXPLAIN 又不直接告诉你它放弃了什么。
