mysql 8.0才真正支持降序索引，5.7及更早版本会忽略desc；降序索引生效需满足版本、引擎、语法、where条件、select字段和排序方向全部匹配，explain中出现using filesort即未生效。
建索引时必须显式写 DESC，否则等于没建
MySQL 8.0 才真正把 DESC 当成有效语法；5.7 及更早版本虽然允许写 CREATE INDEX idx ON t(col DESC)，但 SHOW CREATE TABLE 会显示它被悄悄转成了升序。验证方式很简单：SHOW CREATE TABLE t 输出里如果还保留着 col DESC，才是真生效。
常见错误是以为“写了 DESC 就万事大吉”，结果建完发现执行计划里 key 字段压根不出现——那大概率是版本不对、引擎不是 InnoDB，或者语法漏了 DESC（比如只写了 (status, created_at)，没写 created_at DESC）。
-
CREATE INDEX idx_status_ctime ON orders (status, created_at DESC)✅ 正确 -
CREATE INDEX idx_ctime ON orders (created_at DESC)⚠️ 单列降序索引对纯ORDER BY created_at DESC查询，优化器常不选反向扫描，实际仍Using filesort -
CREATE INDEX idx ON orders (status DESC, created_at DESC)❌ 若查询是WHERE status = 'done' ORDER BY created_at DESC，这个索引就浪费了：第一列方向错，无法锚定最左前缀
EXPLAIN 里看 Using filesort 就等于没用上降序能力
判断降序索引是否起效，唯一可靠依据是 EXPLAIN 的 Extra 字段。只要里面还有 Using filesort，说明 MySQL 没跳过排序步骤——哪怕 key 显示用了你建的索引，也白搭。
真正有效的信号是：key 对应你的索引名 + type 是 ref 或 range + Extra 里没有 Using filesort（最好还有 Using index）。
- 查
WHERE status = 'done' ORDER BY created_at DESC，建了INDEX(status, created_at DESC)后，rows应明显缩小（只扫匹配status的行），而非全表行数 - 查
WHERE status IN ('done','pending') ORDER BY created_at DESC，8.0.20+ 版本才较稳定支持排序；低版本仍可能触发Using filesort - 查
WHERE created_at > '2025-01-01' ORDER BY created_at DESC，范围条件直接让created_at DESC部分失效，索引退化为普通查找
多列混合方向索引必须和查询顺序完全对齐
联合索引中 ASC/DESC 不是装饰，它决定了 B+ 树叶子节点的物理存储顺序。MySQL 只能按定义方向前向扫描，不能中途翻转。
例如：INDEX(a ASC, b DESC) 只能加速 ORDER BY a ASC, b DESC 或 ORDER BY a ASC；换成 ORDER BY a ASC, b ASC 就完全不适用——物理顺序相反，没法复用。
- 要支持
WHERE category = ? ORDER BY price DESC, id ASC，就得建INDEX(category, price DESC, id ASC) - 同一列不能重复指定方向：
(a ASC, a DESC)直接报语法错误 - 两列都
DESC（如INDEX(a DESC, b DESC)）只对ORDER BY a DESC, b DESC有效，别指望它还能优化ASC查询
覆盖查询 + 降序索引才能彻底避免回表和排序
如果 SELECT 的字段不全在索引里，即使索引方向对、WHERE 条件也匹配，MySQL 还得回表取数据；而回表后的结果集无法保证全局有序，最终仍会补上 Using filesort。
真正发挥降序索引价值的场景，是过滤、排序、返回字段三者全部被一个索引覆盖。
- 想查
SELECT id, title FROM posts WHERE status = 'published' ORDER BY created_at DESC LIMIT 20，就该建INDEX(status, created_at DESC, id, title) -
NULL值在DESC索引里排最前（因 MySQL 视NULL为最小值），若业务要求NULL排最后，得在查询里显式处理，比如ORDER BY created_at DESC, id DESC并补唯一列防重复 - 单列
INDEX(created_at DESC)在真实分页中基本没用——业务分页几乎都带等值过滤条件，必须用联合索引
ORDER BY ... DESC 贴的万能膏药，它的生效极其苛刻：版本、引擎、语法、WHERE 条件类型、SELECT 字段、排序方向，缺一不可。最容易被忽略的是 EXPLAIN 里那个小小的 Using filesort ——只要它还在，前面所有操作都白费。
