MySQL 降序索引怎样配合排序查询

MySQL 的降序索引不是把所有排序都自动变快，关键在于索引列顺序和 ORDER BY 的方向是否对应。对于“租户固定、时间倒序、相同时间再按编号正序”的查询，应把等值过滤列放在前面，再用 DESC 和 ASC 写出相同的复合排序。MySQL 8.4 文档说明，InnoDB 支持降序索引，混合方向的多列索引可以让优化器按更合适的扫描方向读取。

实用结论：先把查询写成“过滤列 + 排序列 + 稳定的同值排序列”，再按同样的方向创建复合索引，最后用 EXPLAIN 判断是否仍然需要额外排序。

先把 ORDER BY 写成索引契约

假设订单列表只查询一个租户，并要求最新订单优先；如果两条订单的创建时间相同，则用递增的订单编号稳定顺序：

-- 中文说明：租户条件固定，时间倒序取最新记录，编号正序用于稳定同值排序
SELECT id, tenant_id, created_at, amount
FROM orders
WHERE tenant_id = 42
ORDER BY created_at DESC, id ASC
LIMIT 20;

这里真正的排序契约是 tenant_id 先参与定位，随后是 created_at DESC，最后是 id ASC。不要只看到“按时间倒序”就创建一个单列时间索引，因为查询还有租户范围和同值时的第二排序条件。

按混合方向创建复合索引

在支持降序索引的 InnoDB 表上，可以直接把排序方向写入索引定义：

-- 中文说明：索引方向与查询的 ORDER BY 保持一致
CREATE INDEX idx_orders_tenant_created_id
ON orders (tenant_id ASC, created_at DESC, id ASC);

tenant_id ASC 主要表达索引键的第一列方向；当它被 = 固定后，后面的时间和编号顺序才是本例的重点。若查询改成 ORDER BY created_at DESC, id DESC，索引的最后一列方向就不再完全匹配；不要用“有索引就一定不排序”来判断。

同一组列如果只需要全升序或全降序，已有的升序索引有时可以被反向扫描。但混合方向无法简单靠一次整体反向解决，这正是显式声明降序键部分的价值。

给同值记录补一个稳定的排序列

时间戳并不保证唯一。如果只写 ORDER BY created_at DESC，第一页和第二页在插入新数据或执行计划变化后，可能出现同一时间记录顺序漂移。将主键或其他唯一列补到排序末尾，可以让分页边界更明确：

-- 中文说明：id 作为同一时间值下的稳定 tie-breaker
SELECT id, created_at, amount
FROM orders
WHERE tenant_id = 42
  AND created_at 

索引列必须服务于真实的排序语义。不要为了“看起来完整”把多个与本次查询无关的字段继续塞进索引；索引越宽，写入成本和存储占用也会增加。

用 EXPLAIN 判断是否真的消除了排序

建立索引后，先看执行计划中的 key、访问类型和排序线索。下面的命令只用于查看计划，不会修改数据：

-- 中文说明：用树形计划观察索引名称、扫描方向和排序节点
EXPLAIN FORMAT=TREE
SELECT id, tenant_id, created_at, amount
FROM orders
WHERE tenant_id = 42
ORDER BY created_at DESC, id ASC
LIMIT 20;

如果索引顺序能覆盖过滤和排序，计划通常会体现为索引扫描；同方向的反向读取可能显示为 reverse 或在 Extra 中出现 Backward index scan。如果排序方向、列顺序或前缀条件不匹配，计划可能增加 filesort。这不是说“磁盘上一定创建了一个文件”，而是优化器需要额外的排序步骤。

判断时不要只看有没有使用索引，还要看使用索引后是否仍然排序，以及是否扫描了过多行。数据量、选择性、LIMIT 大小和统计信息都会影响优化器的最终选择。

常见误区与快速总结

• 不要把单列 created_at DESC 当成带租户过滤和二次排序的完整方案。
• 不要把 ASC、DESC 的顺序写反；混合方向要按完整的 ORDER BY 对齐。
• 不要只凭索引名称判断结果，要用 EXPLAIN 观察扫描和排序节点。
• 降序索引的支持范围与存储引擎有关；本文讨论的是 InnoDB 的普通 B-Tree 场景。

记住这条设计顺序即可：先确定等值过滤，再列出每个排序字段的方向，最后补一个稳定的唯一排序列。只有查询契约和索引定义一致，降序索引才真正有机会减少排序工作。

相关问题

只有一个 DESC 列时需要显式写 DESC 吗？可以写，尤其是在需要表达查询意图或和复合索引保持一致时；但是否获得收益仍要结合执行计划。

看到 filesort 就一定要加索引吗？不一定。先确认排序结果集大小、LIMIT、过滤选择性和实际响应时间，再决定索引是否值得增加。