降序索引未生效是因为where条件、order by方向与索引定义三者未对齐；必须满足mysql 8.0.12+、索引显式声明desc、where等值最左前缀匹配、order by逐列方向严格一致，且explain中extra无using filesort、type为ref/range、rows显著减少。
INDEX 建了但 EXPLAIN 里还出现 Using filesort？说明降序索引根本没用于排序——不是版本不够、不是语法写错，而是 WHERE 条件、ORDER BY 方向、索引定义三者没对齐。
确认 MySQL 版本和索引是否真被物理存储
MySQL 8.0.12+ 的 InnoDB 才真正支持物理降序键值；8.0.11 及更早版本会静默忽略 DESC，建出来仍是升序索引。
- 执行
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)或INDEX (a ASC, b DESC)都完全不匹配 - 即使你省略了
ASC，也建议显式写出：INDEX (status ASC, created_at DESC)，避免歧义 - 同一列不能在单个索引中重复声明方向，如
(a ASC, a DESC)直接报错ERROR 1064
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→ MySQL 8.0.20+ 才较稳定支持；低版本大概率仍触发Using filesort -
WHERE created_at > '2025-01-01' ORDER BY created_at DESC→ 单列范围查询 + 降序排序，B+ 树物理顺序冲突，优化器倾向放弃索引排序 -
WHERE status = 'done' AND priority > 5 ORDER BY created_at DESC→priority > 5中断最左前缀连续性，created_at DESC失效
验证降序索引是否真正在工作
光看 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配合覆盖索引
INDEX (updated_at DESC)，90% 的场景都浪费空间还拖慢写入。
