mysql 8.0.12+ innodb才真正支持物理降序索引，需满足版本≥8.0.12、show create table显示desc、where最左前缀等值匹配、order by方向与索引逐列严格一致且无函数表达式，否则using filesort无法避免。
Using filesort 还在 EXPLAIN 的 Extra 里？说明降序索引根本没生效——不是建得不够多，而是条件、方向、写法三者没对齐。
确认 MySQL 版本和索引是否真被物理存储
MySQL 8.0.12+ 的 InnoDB 才真正把 DESC 写进 B+ 树；更早版本（包括 8.0.11）会静默忽略，建出来的仍是升序索引。
- 执行
SHOW CREATE TABLE t，输出中必须明确出现col_name DESC字样才算生效 - 查系统表：
SELECT COLLATION FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 't' AND INDEX_NAME = 'idx'，结果为D表示降序，A就是升序（哪怕你写了DESC） -
PRIMARY KEY (id DESC)在 8.0.11 及之前会被强制转成升序，别信语法糖
WHERE 条件必须构成最左前缀等值匹配
降序索引的排序能力不是天生的，它依赖前面的等值条件“锚定”扫描起点。没有这个锚点，DESC 部分就形同虚设。
-
WHERE status = 'done' ORDER BY created_at DESC→ 可用INDEX(status, created_at DESC) -
WHERE status IN ('done', 'pending') ORDER BY created_at DESC→ 多数 8.0.19 及更早版本仍触发Using filesort；8.0.20+ 才较稳定支持 -
WHERE user_id > 100 ORDER BY id DESC→ 单列范围查询 + 降序排序，B+ 树物理顺序冲突，大概率退化为全索引扫描 -
WHERE status = 'done' AND priority > 5 ORDER BY created_at DESC→priority > 5中断最左前缀连续性，created_at DESC失效
ORDER BY 必须逐列与索引方向严格一致
MySQL 不会“部分复用”混合方向索引。方向错一位、少一位、多一位，整个排序逻辑就失效，必然触发 Using filesort。
-
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 DESC完全不匹配，B+ 树物理结构不兼容 -
INDEX(a DESC, b DESC)只优化ORDER BY a DESC, b DESC场景，别指望它也能加速ASC查询 - 同一列不能在单个索引中重复声明方向，如
(a ASC, a DESC)直接报错ERROR 1064
验证索引是否真正在工作
光看 EXPLAIN 的 key 字段命中索引名远远不够，关键盯三处：Extra、type、rows。
-
Extra出现Using filesort→ 没走成索引排序，无论你建了多少个DESC索引 -
type是ref或range，且rows显著小于总行数（比如百万级表降到几千）→ 基本确认走了索引扫描层排序 - MySQL 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划中是否有-> Sort节点；没有则确认排序已下推 - 若查询含
SELECT *，回表后结果不再有序，MySQL 会强制补排序——优先用SELECT id, status, created_at配合覆盖索引
