使用MySQL 8.0降序索引优化倒序排序查询性能

先说结论，避免走弯路：MySQL 8.0.12+ 的降序索引（DESC index）生效条件相当苛刻。只有当 ORDER BY 的方向、列的顺序以及 WHERE 条件中最左侧的等值部分三者全部对齐时，才能真正绕过 filesort。否则，所建的降序索引基本无效，不仅无法提升查询性能，还可能拖慢写入速度。

简单总结：MySQL 8.0.12+ 的降序索引只有在 ORDER BY 方向、列顺序、WHERE 条件三者完全对齐时，才能跳过 Using filesort；其他情况下建立降序索引基本无效，甚至降低写入性能。

确认 MySQL 版本与存储引擎是否真正支持降序索引

首先，确认 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。

单列降序索引搭配 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 降序索引就只是个摆设。