如何在MySQL 8.0中使用降序索引优化倒序排序的查询性能

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 就只是个摆设。