MySQL 8.0.12+ 的 InnoDB 才真正支持物理降序索引，此前版本会静默忽略 DESC；需通过 VERSION()、SHOW CREATE TABLE 和 INFORMATION_SCHEMA.STATISTICS 三重验证是否生效，且 WHERE 最左前缀等值匹配、ORDER BY 方向与索引严格一致才能避免 Using filesort。
CREATE INDEX 语句里写 DESC 不等于索引就真按降序存了——MySQL 8.0.12+ 的 InnoDB 才真正支持物理降序索引，更早版本（包括 8.0.11）会静默忽略 DESC，建出来还是升序索引。
确认 MySQL 版本和索引是否真落地
光看建表语句写了 DESC 没用，必须验证它是否被数据库实际采纳：
- 执行
SELECT VERSION()，确保返回值 ≥8.0.12 - 运行
SHOW CREATE TABLE your_table，输出中必须明确出现类似created_at DESC字样；如果只显示created_at，说明没生效 - 查系统表：
SELECT COLLATION FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'your_table' AND INDEX_NAME = 'your_idx'，结果为D表示降序已落地，A就是升序（哪怕你写了DESC）
ORDER BY 方向必须和索引逐列严格一致
MySQL 不会“部分复用”方向不匹配的联合索引。方向错一位、少一位、多一位，整个排序逻辑就失效，EXPLAIN 的 Extra 字段必然出现 Using filesort：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
INDEX (a DESC, b ASC)只加速ORDER BY a DESC, b ASC，对ORDER BY a DESC, b DESC或ORDER BY a DESC单独使用都无效 -
INDEX (a ASC, b DESC)和ORDER BY a DESC, b ASC完全不兼容，B+ 树物理结构不支持跨方向跳转 - 即使
ASC是默认值，也建议显式写出，避免歧义：比如写INDEX (status ASC, created_at DESC)而非INDEX (status, created_at DESC)
WHERE 条件必须构成最左前缀等值匹配
降序索引的排序能力不是天生的，它依赖前面的等值条件“锚定”扫描起点。没有这个锚点，DESC 部分就形同虚设：
-
WHERE status = 'done' ORDER BY created_at DESC→ 可用INDEX (status ASC, created_at DESC) -
WHERE created_at > '2025-01-01' ORDER BY created_at DESC→ 单列范围 + 降序排序，B+ 树无法同时满足定位与倒序读取，大概率退化为全索引扫描 -
WHERE status IN ('done', 'pending') ORDER BY created_at DESC→ MySQL 8.0.19 及更早版本仍可能触发Using filesort；8.0.20+ 才较稳定支持 -
WHERE status = 'done' AND priority > 5 ORDER BY created_at DESC→priority > 5中断最左前缀连续性，created_at DESC失效
验证降序索引是否真正在工作
不能只看 EXPLAIN 的 key 字段是否命中索引名，关键盯三处：
-
Extra字段必须不含Using filesort（截至 2026 年 9 月仍是核心判断依据） -
type应为ref或range，而非ALL或index -
rows值应明显小于总行数（比如百万级表降到几千），否则只是“命中索引名”，没真正走索引排序路径 - MySQL 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划里有没有-> Sort节点；没有则确认排序已下推
DESC 就只是语法糖。 
