MySQL 8.0.12+ 的 DESC 索引仅在版本≥8.0.12、InnoDB引擎、SHOW CREATE TABLE 显示 DESC、WHERE 最左前缀等值匹配、ORDER BY 方向与索引逐列严格一致时才跳过 filesort，否则无效甚至拖慢性能。
MySQL 8.0.12+ 的 DESC 索引不是“开启”就能用的，它必须满足版本、语法、查询结构三者严丝合缝，否则建了也白建，甚至拖慢写入。
确认 MySQL 版本和存储引擎是否真正支持物理降序索引
低于 8.0.12 的版本（包括 8.0.11）会静默忽略 DESC 关键字，建出来的仍是升序索引。InnoDB 是唯一支持物理降序存储的引擎，MyISAM 不支持。
- 执行
SELECT VERSION()，确保返回值 ≥8.0.12 - 运行
SHOW CREATE TABLE your_table，检查输出中是否明确出现类似created_at DESC—— 如果只显示created_at，说明没生效 - 查系统表：
SELECT COLLATION FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'your_table' AND INDEX_NAME = 'your_idx'，结果为D才代表降序已落地（A表示升序）
建索引时必须显式声明每列方向，且联合索引方向要与 ORDER BY 逐列严格一致
MySQL 不会“部分复用”混合方向索引。方向错一位、少一位、多一位，整个排序逻辑就失效，必然触发 Using filesort。
-
ORDER BY a DESC, b ASC必须配INDEX (a DESC, b ASC)；INDEX (a DESC, b DESC)完全不匹配 - 即使
ASC是默认值，也建议显式写出，避免歧义：INDEX (status ASC, created_at DESC) - 同一列不能在单个索引中重复声明方向，如
(a ASC, a DESC)直接报错ERROR 1064 -
PRIMARY KEY (id DESC)在 8.0.11 及之前会被强制转成升序，别信语法糖
WHERE 条件必须构成最左前缀等值匹配，否则 DESC 部分形同虚设
降序索引的排序能力依赖前面的等值条件“锚定”扫描起点。没有这个锚点，DESC 就无法下推到扫描层。
- 有效组合：
WHERE status = 'done' ORDER BY created_at DESC→ 对应INDEX (status ASC, created_at DESC) - 无效组合：
WHERE created_at > '2025-01-01' ORDER BY created_at DESC→ 单列范围 + 降序排序，B+ 树物理顺序冲突，大概率退化为全索引扫描 -
WHERE status IN ('done', 'pending') ORDER BY created_at DESC：8.0.19 及更早版本仍常触发Using filesort；8.0.20+ 才较稳定支持 -
WHERE status = 'done' AND priority > 5 ORDER BY created_at DESC：priority > 5中断最左前缀连续性，created_at DESC失效
验证降序索引是否真正在工作，不能只看 key 字段命中
光看 EXPLAIN 的 key 字段是否命中索引名远远不够，关键盯三处：Extra、type、rows。
-
Extra出现Using filesort→ 没走成索引排序，无论你建了多少个DESC索引 -
type是ref或range，且rows显著小于总行数（比如百万级表降到几千）→ 基本确认走了索引扫描层排序 - 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划中是否有-> Sort节点；没有则确认排序已下推 - 若查询含
SELECT *，回表后结果不再有序，MySQL 会强制补排序——优先用SELECT id, status, created_at配合覆盖索引
最常被忽略的是 NULL 值语义：在 DESC 索引中，NULL 默认排在最前面（MySQL 视其为最小值），和 ASC 索引相反，容易导致业务分页或排名逻辑偏差。
