MySQL 8.0+ InnoDB 支持降序索引，但需显式声明 DESC 且满足最左前缀、方向一致、覆盖查询三条件；否则仍触发 Using filesort。
ORDER BY id DESC 走不了索引？先看执行计划里 key 和 Extra 字段
MySQL 对降序索引的支持取决于版本和存储引擎。5.7 及之前默认不支持 DESC 索引定义，即使写 CREATE INDEX idx ON t(id DESC)，也会被忽略成升序；8.0+ 才真正支持多列混合排序方向的索引，且仅限 InnoDB。
判断是否生效最直接的方式是 EXPLAIN SELECT ... ORDER BY id DESC，重点看：
– key 是否命中你建的索引
– Extra 是否出现 Using filesort（有它就说明没走索引排序）
- 如果
ORDER BY字段和WHERE条件字段共同构成最左前缀，且排序方向与索引定义一致，才可能跳过排序步骤 -
WHERE a = 1 ORDER BY b DESC能用INDEX(a, b DESC)；但WHERE a > 1 ORDER BY b DESC中，a是范围查询，b的排序方向就失效了 - 8.0 下建混合方向索引必须显式写
DESC，比如CREATE INDEX idx ON t(a ASC, b DESC)，只写ASC不写DESC默认仍是升序
复合索引中 ASC/DESC 混用的实际效果：不是所有组合都等价
索引的排序能力本质是 B+ 树叶子节点的物理顺序。一旦某列用了 DESC，后续列的“自然扫描方向”就变了——这直接影响 ORDER BY 能否复用索引顺序。
-
INDEX(a ASC, b DESC)支持：ORDER BY a ASC, b DESC、ORDER BY a ASC，但不支持ORDER BY a ASC, b ASC -
INDEX(a DESC, b ASC)支持：ORDER BY a DESC, b ASC，但不支持ORDER BY a DESC, b DESC - 两列都
DESC（INDEX(a DESC, b DESC)）等价于把整个索引倒过来建，只适合ORDER BY a DESC, b DESC场景，别指望它能优化ASC查询 - MySQL 8.0 不支持在同一个索引中对同一列指定不同方向（比如
a ASC, a DESC），语法报错
覆盖索引 + 降序：避免回表的同时省掉排序，但要注意 WHERE 条件的约束力
如果查询只需要索引字段（比如 SELECT id FROM t WHERE status = 1 ORDER BY id DESC），且 INDEX(status, id DESC) 存在，就能同时满足过滤、排序、覆盖三重目标——这是降序索引最有价值的场景。
- 务必确认
SELECT列全在索引中，否则会触发回表，而回表后的结果集无法保证全局有序，MySQL 仍会加Using filesort -
WHERE条件必须能利用索引最左前缀，哪怕只是单列等值（如status = 1），才能让id DESC部分生效；如果是status IN (1,2)，部分版本可能退化为范围扫描，排序能力减弱 - 注意
NULL值处理：在DESC索引中，NULL默认排在最前面（因为 MySQL 把NULL视为最小值），和ASC索引相反，容易导致业务语义偏差
升级到 MySQL 8.0 后仍走不了 ORDER BY ... DESC？检查隐式类型转换和函数包裹
即便索引定义正确、版本够新，常见干扰项仍会让优化器放弃使用降序索引：
-
ORDER BY ABS(id) DESC或ORDER BY UPPER(name) DESC：函数包裹直接导致索引失效 -
WHERE id + 0 = 123：隐式类型转换（比如字段是CHAR，但传入数字）会让id列无法走索引，连带后面的排序也无效 -
JOIN表的连接顺序或驱动表选择不当，可能导致排序发生在临时表上，而非原表索引上 - 查询中含
UNION、子查询或窗口函数时，ORDER BY的作用域可能脱离索引上下文，需单独分析执行计划
降序索引不是银弹——它只在「过滤条件精准锚定索引前缀 + 排序字段方向严格匹配 + 查询列被完全覆盖」这三点同时满足时，才真正省掉排序开销。少一个条件，Using filesort 就大概率回来。
