mysql 8.0.12+ 的降序索引仅在 order by 方向、列顺序、where 等值最左前缀三者完全对齐时才能跳过 filesort；否则无效甚至拖慢性能，需通过 show create table、information_schema.statistics 和 explain 验证是否真正生效。
MySQL 8.0.12+ 的降序索引只有在 ORDER BY 方向、列顺序、WHERE 条件三者全部对齐时，才能真正跳过 Using filesort；其他情况建了也白建，甚至拖慢写入。
确认你的 MySQL 版本和存储引擎是否真正支持 DESC 索引
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才代表降序已落地
ORDER BY a DESC, b ASC 必须配 INDEX (a DESC, b ASC)
方向不一致不是“部分生效”，而是整个排序逻辑无法下推。MySQL 不会把 INDEX (a DESC, b DESC) 用于 ORDER BY a DESC, b ASC，也不会用 INDEX (a ASC, b DESC) 去匹配它。
- 联合索引中每列的
ASC/DESC必须和ORDER BY子句逐列严格一致，包括显式写出ASC（虽然省略默认就是ASC，但建议写全以防歧义） -
ORDER BY a DESC, b ASC, c DESC→ 索引必须是(a DESC, b ASC, c DESC)，缺一不可 - 哪怕只错一个方向，EXPLAIN 的
Extra字段仍会出现Using filesort
单列 DESC 索引 + WHERE 范围条件 = 几乎无效
这是最常踩的坑：以为建了 INDEX (updated_at DESC)，再写 WHERE updated_at > '2025-01-01' ORDER BY updated_at DESC 就能又过滤又排序——实际 B+ 树无法同时满足范围扫描和倒序读取的物理顺序要求，往往退化为全索引扫描。
- 真正有效的组合是「高选择性等值条件 + 排序列 DESC」，例如：
WHERE status = 'done' AND updated_at > '2025-01-01' ORDER BY updated_at DESC - 对应索引应为
INDEX (status, updated_at DESC)，把等值列放最左 - 如果只写
WHERE updated_at > '2025-01-01' ORDER BY updated_at DESC，优化器大概率选Backward index scan（旧版 fallback 行为），或干脆全表扫 +filesort
验证降序索引是否真正在工作
不能只看 EXPLAIN 的 key 字段是否命中索引名，关键盯紧三处：
-
Extra列必须不出现Using filesort或Using temporary；理想状态是空，或仅Using index -
type应为ref、range或index，而非ALL -
rows值应明显小于表总行数（比如从百万级降到几千），说明走了索引范围扫描，而非全表+排序 - MySQL 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划里有没有-> Sort节点；没有才表示跳过了排序
真正难的从来不是写 CREATE INDEX ... DESC 这一行语法，而是让查询的 WHERE 条件、ORDER BY 方向、索引列顺序、列类型四者严丝合缝对齐——漏掉任意一环，DESC 就只是个摆设。
