首先给出结论，避免大家绕弯路：MySQL 8.0.12 及以上版本的降序索引，生效条件极为严格。只有当 ORDER BY 的方向、列的顺序、以及 WHERE 条件中最左侧的等值部分三者完全对齐时，才能真正绕过 filesort。否则，你创建的降序索引基本形同虚设，不仅没用，还可能拖慢写入性能。
简而言之，MySQL 8.0.12 及以上版本的降序索引，只有在 ORDER BY 方向、列顺序、WHERE 条件三者全部对齐时，才能真正跳过 Using filesort；其他情况建了也白费力气，甚至降低写入效率。
确认你的 MySQL 版本和存储引擎是否真正支持 DESC 索引
先检查你的 MySQL 版本是否真正支持降序索引。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 都只是一个华丽的装饰。
