单列DESC索引对倒序分页基本无效，因无WHERE等值条件锚定起点时，优化器倾向全表扫描+filesort而非高成本反向索引扫描；仅当WHERE等值过滤+ORDER BY方向与联合索引逐列严格一致（如INDEX(status, created_at DESC)配WHERE status='done' ORDER BY created_at DESC）时才真正跳过filesort。
加了 INDEX (created_at DESC) 却仍出现 Using filesort，说明索引根本没用于排序——降序索引不是建了就生效，它只在「等值过滤 + 方向严格匹配」的组合下才跳过排序。
为什么单列 DESC 索引对倒序分页基本无效
纯 ORDER BY created_at DESC LIMIT 20 查询，即使建了 INDEX (created_at DESC)，优化器也大概率不选反向扫描。原因很实际：没有 WHERE 条件锚定起点，B+ 树倒序遍历的 I/O 成本未必优于正向扫主键 + 内存排序。
-
EXPLAIN中type是ALL或index，且Extra含Using filesort→ 白建 - MySQL 8.0.12+ 才真正存储物理降序键值；更早版本会静默忽略
DESC，SHOW CREATE TABLE里看不到DESC字样就是没生效 - 单列降序索引遇上范围条件（如
WHERE created_at > '2025-01-01'）直接失效：B+ 树无法同时满足“范围定位”和“倒序读取”的物理顺序
WHERE status = ? ORDER BY created_at DESC 必须配联合索引
真实分页几乎都带状态过滤，这时必须把等值列放前、排序列放后，并显式声明方向：INDEX (status ASC, created_at DESC)。
- 这个索引只加速
WHERE status = 'done' ORDER BY created_at DESC这一种组合，换方向或漏条件就退化 - 方向必须逐列一致：
INDEX (status, created_at DESC)不支持ORDER BY created_at DESC单独用，也不支持ORDER BY status DESC, created_at DESC -
WHERE status IN ('done', 'pending')在 MySQL 8.0.20+ 才较稳定启用排序能力；低版本可能仍触发Using filesort
如何验证降序索引真正在工作
别只盯 key 字段是否命中索引名，关键看三处：是否跳过排序、是否缩小扫描行数、是否避免回表。
-
Extra字段必须不含Using filesort，最好还有Using index（覆盖索引） -
type应为ref或range，rows值应明显小于总行数（比如从百万级降到几千） - MySQL 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划中是否有-> Sort节点；没有则确认排序已下推 - 用
sys.schema_unused_indexes定期清理长期未命中的降序索引——它比升序索引占更多空间，维护成本更高
最容易被忽略的一点是：如果查询含 SELECT *，回表后结果不再有序，MySQL 会强制补排序。所以优先用 SELECT id, status, created_at 配合覆盖索引，否则再好的降序索引也白搭。
