mysql 8.0.12+ 才真正支持 desc 物理降序索引，需版本≥8.0.12、show create table 显示明确 desc、order by 方向与索引逐列严格一致、where 有最左等值条件，且配合覆盖索引才能避免 using filesort。
DESC 索引不是加了就自动跳过 Using filesort，它只在极少数精准匹配的场景下才真正生效；多数人建了反而浪费空间、拖慢写入，还误以为问题已解决。
确认 MySQL 版本和索引是否物理落地
MySQL 8.0.12+ 的 InnoDB 才真正把 DESC 当作物理排序方向存进 B+ 树；8.0.11 及更早版本会静默忽略，SHOW CREATE TABLE 输出里看着写了 created_at DESC，实际建出来仍是升序索引。
- 执行
SELECT VERSION()，确保返回值 ≥8.0.12 - 运行
SHOW CREATE TABLE your_table，检查输出中是否明确出现col_name DESC—— 如果只显示col_name，说明没生效 - 查系统表：
SELECT COLLATION FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_NAME = 'your_table' AND INDEX_NAME = 'your_idx' AND SEQ_IN_INDEX = 1，返回D才表示首列是降序（A是升序） -
MyISAM不支持倒序索引，哪怕版本够也不行
ORDER BY 必须与索引逐列方向严格一致
方向错一位，整个索引对排序就失效。MySQL 不会“部分复用”混合方向索引，也不会把 ASC 列自动转成 DESC 来凑。
- 索引是
(status, created_at DESC)→ 只能加速ORDER BY status, created_at DESC - 不能用于
ORDER BY created_at DESC单独出现，也不能用于ORDER BY status DESC, created_at DESC - 要优化
ORDER BY user_id DESC, updated_at ASC，必须显式建INDEX (user_id DESC, updated_at ASC) - 写成
INDEX (user_id DESC, updated_at)（省略ASC）虽语法合法，但可读性差，且某些旧客户端解析可能出偏差 -
ORDER BY DATE(created_at) DESC这类函数表达式，无论索引怎么建，都强制走Using filesort
WHERE 条件必须压住最左前缀等值匹配
没有这个锚点，DESC 部分就形同虚设。单列 INDEX (updated_at DESC) 配 WHERE updated_at > '2025-01-01' ORDER BY updated_at DESC，B+ 树物理扫描方向与逻辑倒序需求冲突，极易退化为全索引扫描。
- 真正有效的组合是：高选择性等值条件 + 倒序排序列，例如
WHERE status = 'done' ORDER BY updated_at DESC，对应索引必须是(status, updated_at DESC) - 如果
status基数很低（比如只有 3 个值），这个索引效果也会打折扣 -
WHERE status IN ('done', 'pending')在 8.0.19 及更早版本仍大概率触发Using filesort；8.0.20+ 才较稳定支持 -
WHERE user_id > 100 ORDER BY id DESC这种范围条件 + 降序排序，B+ 树无法同时满足定位和倒序读取，基本无效
验证降序索引是否真正在工作
不能只看 EXPLAIN 的 key 字段是否命中索引名，关键盯紧三处：Extra、type、rows。
-
Extra出现Using filesort→ 排序没走索引，哪怕key显示命中了带DESC的索引 -
Extra不出现Using filesort，且type是ref或range，rows远小于总行数 → 基本确认排序已下推到索引扫描层 - MySQL 8.0.20+ 可用
EXPLAIN FORMAT=TREE，直接看执行计划里有没有-> Sort节点；没有则确认排序已下推 - 若查询含
SELECT *，回表后结果不再有序，MySQL 会强制补排序——优先用SELECT id, status, created_at配合覆盖索引
