复合索引中范围查询后order by失效，因b+树仅保证最左前缀有序，范围条件后字段在磁盘无序；可改用等值约束排序字段、覆盖索引或分步查询绕过。
为什么WHERE中用了范围查询，ORDER BY就失效了
复合索引的B+树只保证“前缀有序”，一旦某个字段用了范围条件（>、、<code>BETWEEN、LIKE 'abc%'），后续字段在物理存储上就不再连续有序。MySQL无法跳过前缀直接对后缀字段排序，所以ORDER BY只能退化为Using filesort。
比如索引是 (status, created_at, id)，执行：SELECT * FROM t WHERE status = 'active' AND created_at > '2025-01-01' ORDER BY id;
——status是等值，created_at是范围，那么id在磁盘上是散列分布的，索引无法提供id的排序能力。
哪些写法能绕过这个限制
核心思路是让排序字段参与索引“最左前缀”的等值约束，或用覆盖索引避免回表+排序。
- 把排序字段提前到WHERE条件中：如果业务允许，改用
WHERE status = ? AND id = ?再加ORDER BY created_at，此时id成了等值条件，created_at就能走索引排序 - 拆分查询：先用范围条件查出主键ID列表（带
LIMIT），再用IN二次查询并显式ORDER BY——前提是ID数量可控，否则IN过大反而慢 - 建覆盖索引：例如常查
SELECT name, score FROM exam WHERE subject IN ('math', 'english') ORDER BY score DESC，可建INDEX idx_subj_score_name (subject, score, name)，这样ORDER BY score能复用索引，且无需回表
容易被忽略的两个坑
一是LIKE不是万能通配符：只有LIKE 'prefix%'算等值前缀扫描；LIKE '%suffix'或LIKE '%mid%'直接让整个索引失效，连WHERE都走不了，更别说ORDER BY。
二是隐式类型转换：比如WHERE status = 1但status是字符串类型，MySQL会转成WHERE CAST(status AS SIGNED) = 1，导致索引无法用于排序——检查EXPLAIN的type是否还是ref或range，而不是ALL。
替代方案：不依赖索引排序时怎么做
当数据量不大（比如rows ）且并发不高，可以接受<code>filesort，但必须控制内存开销：
- 用
SET SESSION sort_buffer_size = 2097152临时调高单次查询内存，比全局改更安全 - 避免
SELECT *：只选必要字段，减少每行体积，让sort_buffer能塞更多行，降低落盘概率 - 监控
Sort_merge_passes：持续上升说明频繁磁盘排序，这时才考虑调参或重构逻辑
真正卡住的往往不是sort_buffer_size大小，而是索引没设计成能自然承载“过滤 + 排序”双路径的结构。
