能，但仅当ORDER BY方向与降序索引定义逐列严格一致时才跳过FileSort；混合方向索引不可部分复用，需通过EXPLAIN的Extra字段及key命中情况验证。
MySQL 8.0 降序索引真能跳过 FileSort 吗？
能，但只在特定条件下生效。MySQL 8.0 引入了对 DESC 显式排序方向的索引支持（即「降序索引」），不再是 5.7 那样统一转成升序存储再逆序扫描。但关键点在于：**只有当 ORDER BY 子句的排序方向与索引定义完全一致时，才能避免 FileSort**。
常见误判是以为建了 INDEX (a DESC, b ASC) 就能加速 ORDER BY a DESC, b DESC —— 实际会触发 FileSort，因为 b 方向不匹配。
- 索引定义方向必须和
ORDER BY列顺序、方向逐列严格一致 - 混合方向索引（如
(a ASC, b DESC)）只能用于对应混合顺序的ORDER BY，不能“部分复用” - WHERE 条件中的等值列必须是索引最左前缀，否则无法利用后续排序字段
怎么验证降序索引是否真的跳过了 FileSort？
看 EXPLAIN 的 Extra 字段最直接。如果出现 Using filesort，说明没走成索引排序；如果只有 Using index 或空，且 type 是 range/ref，基本可确认生效。
注意：MySQL 8.0.20+ 还支持 EXPLAIN FORMAT=TREE，能更清晰看到是否用了 “filesort” 节点。
- 执行
EXPLAIN SELECT * FROM t ORDER BY c1 DESC, c2 DESC; - 检查
key字段是否命中你建的降序索引名 - 确认
rows值是否显著小于全表行数（说明走了索引范围扫描，而非全表+排序）
降序索引的创建语法和隐含成本
语法本身简单：CREATE INDEX idx_c1d_c2d ON t (c1 DESC, c2 DESC);，但背后有两点容易被忽略：
- 降序索引在 InnoDB 中实际存储为反向键值（比如字符串按字节逆序编码），这意味着它和对应升序索引 **无法共用** —— 你既需要
ASC又需要DESC排序场景时，得建两套索引，空间翻倍 - MySQL 8.0.12+ 才支持在主键中使用
DESC；8.0.11 及之前版本主键强制升序，即使显式写PRIMARY KEY (id DESC)也会被忽略 - 覆盖查询（
SELECT c1,c2）搭配降序索引时，仍可走Using index，但若SELECT *且表有大字段（如TEXT），回表开销依然存在
比降序索引更值得优先检查的 FileSort 根源
很多 case 其实根本不需要降序索引——问题出在查询设计或索引缺失上。
- 先确认是否漏掉了等值过滤条件：比如
WHERE status = 1 ORDER BY created_at DESC，应该建INDEX (status, created_at DESC)，而不是单独给created_at建降序索引 - 检查是否用了函数或表达式：如
ORDER BY DATE(created_at) DESC，任何索引都无效，必须改写为范围查询或加生成列索引 - 留意隐式类型转换：
WHERE user_id = '123'（字符串）对比INT字段，会导致索引失效，进而迫使 FileSort
降序索引是把双刃剑：它解决的是「方向匹配」问题，不是万能的排序加速器。真正卡性能的，往往是 WHERE 条件没走索引，或者排序字段根本不在索引里 —— 这些比纠结 ASC/DESC 重要得多。
