MySQL 5.7及更早版本不支持混合方向索引，联合索引中所有字段实际按升序存储，因此ORDER BY a DESC, b ASC无法命中(a, b)索引；而MySQL 8.0+支持单字段独立排序方向，但要求ORDER BY方向与索引定义严格一致。
MySQL 5.7 及更早版本不支持混合方向索引，联合索引中所有字段实际按升序存储，所以 ORDER BY a DESC, b ASC 无法命中 (a, b) 索引。
MySQL 5.7 中 DESC 声明被忽略
建索引时写 ALTER TABLE t ADD INDEX idx_ab (a DESC, b ASC)，MySQL 5.7 会静默忽略 DESC，实际仍按 (a ASC, b ASC) 存储。这意味着：
- 查询
ORDER BY a ASC, b ASC可走该索引 - 但
ORDER BY a DESC, b ASC或ORDER BY a DESC, b DESC都会触发Using filesort - 即使
EXPLAIN显示key被选中，Extra列出现Using filesort就说明排序没复用索引顺序
MySQL 8.0+ 支持单字段独立排序方向
8.0 开始真正支持混合方向定义，例如 CREATE INDEX idx_ab ON t (a ASC, b DESC) 是有效且可被利用的。但必须满足：
- 所有子句排序方向与索引定义严格一致：
ORDER BY a ASC, b DESC✅；ORDER BY a DESC, b DESC❌（a 方向不匹配） - WHERE 条件仍需遵循最左前缀：若只有
WHERE b = ?，则(a ASC, b DESC)索引无法用于过滤或排序 - 范围查询后字段失效：若
WHERE a > 100 ORDER BY b DESC，因a是范围条件，b无法参与索引排序路径
为什么不能“自动反转”索引扫描顺序？
B+ 树索引天然支持双向遍历，但 MySQL 优化器只在「整段连续有序」前提下才跳过排序。问题出在联合索引的物理结构上：
-
(a, b)索引中，数据先按a升序排，a相同时再按b升序排 —— 这是一个二维单调序列 - 要支持
a DESC, b ASC，需要的是“a降序主序、b升序次序”的树结构，和(a ASC, b ASC)的物理布局不兼容 - 优化器不会在运行时动态反向扫描并重排
b，因为那等价于全量读取 + 内存排序，不如直接Using filesort
绕过限制的实操选择
不升级 MySQL 或无法改索引定义时，可考虑：
- 统一改写为同向排序：把业务逻辑从
ORDER BY a DESC, b ASC改成ORDER BY a DESC, b DESC，再建(a DESC, b DESC)索引（8.0+）或(a, b)（5.7 下也能走） - 拆成两个单列索引 + 应用层合并：适用于分页深度小、结果集可控的场景，避免数据库端复杂排序
- 用生成列（generated column）+ 索引模拟逆序：例如增加
rev_b INT AS (-b)并建索引，把ORDER BY b ASC转为ORDER BY rev_b DESC，但要注意溢出和类型限制
最容易被忽略的是：开发环境用 MySQL 8.0 测试通过了混合方向索引，上线后生产库仍是 5.7，DESC 定义完全失效，而 EXPLAIN 又看不出区别——务必核对 SELECT VERSION() 和执行计划中的 Extra 是否真无 Using filesort。
