MySQL 8.0 降序索引真的可以避免 ORDER BY 排序吗？
答案是肯定的，但有一个至关重要的前提：必须满足特定的查询条件。MySQL 8.0 引入的降序索引（INDEX (col DESC)）实现了物理上的降序存储，与早期版本中“逻辑降序、物理升序”的实现方式截然不同。这意味着，当你的查询语句恰好是 ORDER BY col DESC，并且该列上已经建立了对应的降序索引时，查询优化器很可能会直接利用索引的有序性来读取数据，从而跳过昂贵的 filesort 排序操作。
然而，在实际应用中，开发者常常会遇到这样的疑问：为什么已经创建了索引，EXPLAIN 的输出中仍然显示 Extra: Using filesort？或者，创建了一个 INDEX (a DESC, b ASC) 的联合索引，执行 ORDER BY a DESC, b DESC 时排序依然无法避免——问题的根源通常在于排序方向未能完全匹配。
- 降序索引仅对方向完全一致的排序查询生效。例如，索引定义为
(a DESC, b ASC)，它只能优化ORDER BY a DESC, b ASC这类查询，对于ORDER BY a DESC, b DESC则无能为力。 - 对于复合索引，
ORDER BY子句中列的顺序以及每个列的升序（ASC）或降序（DESC）方向，必须与索引定义保持完全一致，否则就无法利用索引跳过排序。 - 此外，
WHERE条件中使用的列必须是索引的最左前缀，并且所使用的比较操作符不能破坏索引的顺序性。举例来说，WHERE a > 10通常可以，但像WHERE a != 10或WHERE a IN (...)这类非等值或范围条件，可能导致优化器放弃使用索引进行排序优化。
可以，但前提是ORDER BY子句的顺序和方向（ASC/DESC）必须与降序索引的定义完全吻合，同时WHERE条件需满足最左前缀原则且操作符不破坏顺序性，这样才能有效跳过filesort。
如何创建真正有效的降序索引？
首先需要更新一个旧有认知。在 MySQL 5.7 及之前的版本中，即使你定义了 INDEX (col DESC)，数据库底层实际创建的仍然是普通的升序索引，降序只是一个逻辑上的约定。直到 MySQL 8.0，才真正支持了物理存储层面的降序索引。因此，不能再沿用过去的经验。
那么，哪些业务场景最适合使用降序索引呢？典型的应用包括：分页查询中获取最新的数据（例如“查询最近的20条订单”）、信息流按时间倒序展示，或者生成从高到低的销量排行榜等。
- 创建索引时，务必显式指定
DESC关键字，例如：CREATE INDEX idx_created_desc ON orders (created_at DESC); - 设计联合索引时需要精心规划方向的组合。例如，
CREATE INDEX idx_status_created ON orders (status ASC, created_at DESC);这个索引，就非常契合WHERE status = 'shipped' ORDER BY created_at DESC这类常见查询。 - 避免创建没有对应查询需求的冗余索引。如果你创建了一个
(a ASC, b DESC)的索引，但业务代码中全是ORDER BY a DESC, b ASC的排序，那么这个索引基本上就失去了其优化价值。
EXPLAIN 结果中没有 Using filesort 就一定使用了索引排序吗？
情况并非如此绝对。没有出现 Using filesort 固然是一个积极的信号，但仍需结合 EXPLAIN 输出中的其他关键字段，如 type 和 key，来综合判断查询是否真正利用了索引的排序特性。
这背后的性能差异非常显著：filesort 意味着需要在内存或磁盘上进行额外的排序操作，涉及大量的 I/O 和 CPU 计算；而利用索引进行顺序扫描则是高效的顺序 I/O，在处理大数据集时性能优势尤为突出。
- 确认
key列显示的是你特意创建的那个降序索引名称，而不是优化器选择的其他索引。 type列的值最好是range、ref或index，如果看到ALL（全表扫描），则说明完全没有使用索引。- 如果
Extra列同时出现Using index且没有Using filesort，那么恭喜——这表示查询使用了覆盖索引，并且完全避免了排序和回表，是性能最优的情况。 - 需要警惕的是，使用
SELECT *很容易导致无法使用覆盖索引，从而引发回表查询。此时即使跳过了排序，整体的查询效率也可能因为大量的随机 I/O 而大打折扣。
哪些细节容易被忽略？
最容易踩坑的地方，往往不是语法错误，而是对特性理解的细微偏差。
- 降序索引不能加速
MIN()/MAX()聚合查询。例如，执行SELECT MIN(created_at) FROM t，即使表上存在INDEX(created_at DESC)，MySQL 为了找到最小值，可能仍需扫描到索引的末端。在这种情况下，一个普通的INDEX(created_at ASC)升序索引，反而能直接读取第一条记录，效率更高。 - 注意 NULL 值的排序行为。在 MySQL 的默认排序规则中，
NULL值被视为最小值，总是排在最前面（无论 ASC 还是 DESC）。但是，NULL值在索引中的物理存储位置取决于存储引擎的具体实现（如 InnoDB），这有时会影响范围查询的边界判断和性能。 - 部分数据类型和场景目前不支持。例如，在分区表上、或对 JSON 列创建函数索引时，目前还不能使用降序修饰符。尝试创建类似
INDEX ((json_col->'$.id') DESC)的索引会导致语法错误。
总而言之，降序索引并非万能钥匙。它的效力完全建立在“查询的排序方向与索引定义的方向精确匹配”这一基础之上。只要方向出现任何不匹配，查询就会退回到 filesort 的传统路径。因此，在创建降序索引之前，最稳妥的做法是使用 EXPLAIN 语句对目标查询进行仔细分析，验证 ORDER BY 子句和计划使用的索引（key）是否能够完美契合。
