MySQL 降序索引怎样配合 ORDER BY 减少排序

列表页总是按最新时间倒序取前几十条时，单纯写 ORDER BY created_at DESC 并不等于 MySQL 一定能省掉排序。更稳妥的做法是把过滤列、排序列和排序方向一起设计进 InnoDB 的 BTREE 联合索引，再用 EXPLAIN 看优化器到底选择了正向扫描、反向扫描，还是仍然落到了 filesort。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/descending-indexes.html

MySQL 8.4 手册明确说明，降序索引会按降序存储键值，混合 ASC/DESC 的多列索引也可以分别对应不同方向的 ORDER BY。但它只解决“索引键怎样排列”这一层，WHERE 条件不匹配左前缀、排序列被函数包住，或者查询还要按索引之外的表达式排序时，仍可能需要额外排序。

先把旧习惯和降序索引分开

过去的常见习惯是只建一个升序索引，然后让服务器反向扫描来满足倒序查询。反向扫描并不是错误，但当查询需要混合方向时，一个只表达 ASC 的索引就不够直观，也未必是更合适的访问路径。降序索引的价值在于把关键列的存储方向明确写进索引定义。

-- 订单列表按创建时间倒序，同一时间再按 id 倒序稳定收尾
CREATE INDEX idx_order_status_created_id
ON orders (status ASC, created_at DESC, id DESC);

-- status 是等值过滤，后面的两个键段负责匹配排序方向
SELECT id, created_at, total_amount
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC, id DESC
LIMIT 50;

这里不是给每一列都机械地加 DESC，而是先看查询契约：status 用来缩小范围，created_at 决定“最新”，id 用来处理同一时间的并列顺序。若没有稳定的第二排序键，分页或重复刷新时可能看到顺序抖动；若第二键的方向写反，联合索引就不再完整表达这条 ORDER BY。

把混合 ASC 和 DESC 写成同一份排序契约

降序索引最适合解决“排序方向不完全相同”的复合查询。例如报表要先按租户升序，再按时间倒序，索引也应该把这两个方向保存下来：

-- 先按租户升序，再让每个租户内部按时间倒序
CREATE INDEX idx_tenant_created
ON audit_logs (tenant_id ASC, created_at DESC);

-- 查询的列顺序和方向与索引键段保持一致
SELECT event_id, tenant_id, created_at, event_type
FROM audit_logs
ORDER BY tenant_id ASC, created_at DESC
LIMIT 100;

如果只是 WHERE tenant_id = ? ORDER BY created_at DESC，第一列是等值条件，后面的时间键仍然可以承担排序。反过来，如果在排序列前面放了一个没有固定值的范围条件，后续键段能否继续用于排序就要谨慎判断，不能只看“索引里包含这些列”。

还要注意索引类型和存储引擎边界：MySQL 8.4 文档说明降序索引支持 InnoDB 和 BTREE，不适用于 HASH、FULLTEXT、SPATIAL；带降序键段的索引也不用于没有 GROUP BY 的 MIN/MAX 优化。索引越多，写入和维护成本越高，所以应围绕真实查询形状建立，而不是为每个排序方向复制一套索引。

用 EXPLAIN 判断是否真的减少排序

建立索引后，重点不是看到 key 有值就宣布成功，而是检查计划是否还包含排序代价。先查看普通计划，再在需要时用树形格式观察扫描方向：

-- 先看优化器选择了哪个索引以及 Extra 提示
EXPLAIN
SELECT id, created_at, total_amount
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC, id DESC
LIMIT 50;

-- 树形计划可以显示索引名后的 reverse 线索
EXPLAIN FORMAT=TREE
SELECT id, created_at, total_amount
FROM orders
WHERE status = 'paid'
ORDER BY created_at DESC, id DESC
LIMIT 50;

普通输出里先看 key 是否是预期的联合索引，再看 Extra 是否出现 Using filesort。树形输出中，索引名后带 (reverse) 表示采用反向索引扫描；这和“完全没用索引”不是一回事，但也不要把反向扫描、正向扫描和 filesort 混成同一个结论。最终要结合实际数据量、过滤选择性和返回列判断收益。

迁移时按这份清单回归

1. 确认目标表使用 InnoDB，索引类型是 BTREE，并确认当前 MySQL 版本支持降序索引语义。
2. 把 WHERE 的等值列放在前面，再按 ORDER BY 的列顺序写入 ASC 或 DESC 键段。
3. 为时间排序补一个稳定的唯一或近似唯一键，避免同值记录在分页时无固定顺序。
4. 同时检查 EXPLAIN 的 key、Extra，必要时查看 FORMAT=TREE 的 reverse 线索。
5. 确认没有 Using filesort 的误判：表达式、函数、跨表排序和未覆盖的排序列都可能让索引无法直接提供顺序。
6. 对写入密集表评估新增索引的存储与维护成本，不要只因为查询带 DESC 就复制索引。

一句话总结：降序索引负责把排序方向写进索引结构，联合索引的左前缀负责把过滤与排序接起来，EXPLAIN 才负责告诉你这份设计是否真的被采用。三者缺一不可。

常见问题

只把 ORDER BY 改成 DESC，就一定会用降序索引吗？

不一定。优化器还要看索引左前缀、过滤条件、排序列是否被表达式包裹，以及查询是否跨表或包含额外排序要求。用 EXPLAIN 观察实际计划。

看到 reverse 就说明索引失效了吗？

不是。reverse 表示反向索引扫描，仍然可能利用索引提供顺序；真正需要继续关注的是是否出现 Using filesort、扫描行数是否过大，以及该计划是否符合当前查询目标。