MySQL 8.0执行器不主动选择降序索引，是否跳过filesort取决于ORDER BY、WHERE和索引定义三者逐列方向对齐；对齐则B+树逆序遍历直接返回有序数据，否则fallback至filesort。
MySQL 8.0 执行器如何用降序索引跳过 filesort
执行器不“主动选择”倒序索引，它完全依赖优化器生成的执行计划；而优化器是否把排序下推到索引层，取决于 ORDER BY 方向、WHERE 条件、索引定义三者是否逐列对齐。只要对齐，InnoDB 就能按 B+ 树物理逆序键值直接遍历，返回的数据天然有序，执行器拿到的就是排好序的行流，根本不需要启动排序流程。
- 对齐意味着：索引列顺序 =
ORDER BY列顺序，且每列方向（ASC/DESC）必须完全一致 - 不对齐时，哪怕只错一个方向（比如索引是
(a DESC, b DESC)，但ORDER BY a DESC, b ASC），执行器收到的输入仍是无序的，只能 fallback 到Using filesort - 单列
INDEX (created_at DESC)配ORDER BY created_at DESC也不保证生效：优化器常认为全表扫描 + 内存排序比反向遍历 B+ 树更便宜，尤其当表小或统计信息不准时
为什么 key 字段显示命中了，却仍有 Using filesort
key 字段只说明用了哪个索引做数据定位，不反映排序是否复用。真正决定是否跳过排序的是 Extra 字段：
- 出现
Using filesort→ 排序没下推，索引仅用于查找，执行器额外启动排序模块 - 空或仅有
Using index→ 排序已由索引物理顺序保障，执行器直接消费有序结果 -
type是ref或range，且rows显著小于总行数 → 说明等值/范围过滤有效，索引真正发挥了“过滤+排序”双重作用
例如：WHERE status = 'done' ORDER BY created_at DESC 命中 INDEX (status, created_at DESC) 后，EXPLAIN 应显示：key: idx_status_created，type: ref，rows: 1247，Extra: Using index
缺任一条件，就退化为查找有效、排序无效。
MySQL 8.0.20+ 的 FORMAT=TREE 能直接验证排序下推
EXPLAIN FORMAT=TREE 输出中，关键看是否有 -> Sort 节点：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 有
-> Sort row sources: ...→ 排序未下推，执行器强制补排序 - 无
-> Sort，只有-> Index lookup或-> Filter→ 排序已在索引扫描层完成
这个视图比传统 EXPLAIN 更直观，避免误读 key 字段带来的假阳性判断。
最容易被忽略的破坏性因素：SELECT *
即使索引完美匹配、EXPLAIN 显示 Using index，一旦查询写成 SELECT *，InnoDB 就必须回表取完整行——而聚簇索引的主键顺序 ≠ 辅助索引的 created_at DESC 顺序，回表后结果天然乱序，执行器只能再补一次 filesort。
- 正确做法：只查需要的列，优先走覆盖索引，例如
SELECT id, status, created_at - 如果业务强依赖
SELECT *，降序索引基本失效，别指望它解决排序问题
降序索引不是开关式优化，它是对查询结构、索引定义、执行路径三者严丝合缝的校验；差一点，就白建。
