mysql 5.7 多列混合排序必触发 using filesort，因其索引不支持物理降序存储，desc 被忽略，b+ 树无法同时满足多列方向不一致的有序扫描；mysql 8.0 支持真正降序索引，需方向逐列严格匹配 order by 才生效。
MySQL 5.7 多列混合排序为什么一定触发 Using filesort
因为 MySQL 5.7 的索引底层只按升序物理存储，哪怕你写 INDEX (a ASC, b DESC)，SHOW CREATE TABLE 一看就发现 DESC 被忽略了，实际建出来是 (a, b) 全升序。当查询是 ORDER BY a ASC, b DESC 时，B+ 树无法同时满足“a 正向有序、b 反向有序”，优化器只能放弃索引排序，走 filesort。
常见错误现象：EXPLAIN 显示 type=ALL 或 Extra: Using filesort，即使 key 字段有值；ORDER BY a DESC, b ASC 在联合索引 (a, b) 上完全不走索引排序。
- MySQL 5.7 不支持物理降序存储，所谓“反向扫描”只是从 B+ 树尾部往前读，但仅适用于单列
ORDER BY col DESC - 多列方向不一致时，反向扫描失效——它不能让第一列正着扫、第二列倒着扫
-
WHERE a = ? ORDER BY b DESC这种单等值 + 单排序还能用索引，但一旦加第三列或换方向就崩
MySQL 8.0 降序索引怎么精准匹配混合排序
MySQL 8.0 真正把 DESC 写进 B+ 树页节点，让索引键值按声明方向物理排序。所以索引 (status ASC, created_at DESC) 就是先按 status 升序分组，每组内再按 created_at 降序排——和 ORDER BY status ASC, created_at DESC 完全对齐。
实操建议：
- 建索引必须显式写出方向：
CREATE INDEX idx_status_created ON orders (status ASC, created_at DESC) - 方向必须和
ORDER BY子句逐列、逐方向一致：ORDER BY status ASC, created_at DESC✅；ORDER BY status ASC, created_at ASC❌（会触发filesort） - WHERE 条件得满足最左前缀：比如
WHERE status = 'paid'可以利用该索引排序；但WHERE created_at > '2025-01-01'就不行，因为没覆盖最左列 - 避免“伪需求”索引：业务里从不查
ORDER BY a DESC, b ASC，却建了(a DESC, b ASC)，这个索引基本闲置
EXPLAIN 里哪些字段说明真用了降序索引排序
光看 key 显示索引名不够，关键要确认是否跳过了排序。真正生效的标志是：type 是 range 或 ref（不是 ALL），且 Extra 里**没有** Using filesort，最好还有 Using index。
容易被忽略的细节：
-
Extra: Using index; Using where✅：既走索引扫描，又免排序，还覆盖 -
Extra: Using index condition; Using filesort❌：虽然用了索引过滤，但排序仍靠filesort -
SELECT *容易让覆盖失效，导致回表，此时即使免了排序，I/O 量也不小 - 如果
key_len比预期小（比如联合索引两列，但key_len只显示第一列长度），说明第二列方向没对上，没参与排序
什么时候降序索引反而没用
降序索引不是银弹。以下场景它帮不上忙：
-
MIN()/MAX()查询：比如SELECT MIN(created_at) FROM t，哪怕有INDEX(created_at DESC)，优化器也不会用——B+ 树最小值永远在最左，降序索引的最左是最大值 - 范围查询后接排序：如
WHERE a > 10 ORDER BY b DESC，a > 10是范围，索引无法保证后续b的顺序性，大概率退化为filesort - 使用函数或表达式：
ORDER BY UPPER(name) DESC，索引失效，降序索引也救不了 - 非 InnoDB 表：降序索引只支持 InnoDB，MyISAM 或 Memory 引擎下
DESC依然被忽略
最常被低估的一点：降序索引的价值不在“能建”，而在“是否和真实查询模式严丝合缝”。少一个 ASC、多一个等值条件位置错位，就回到 filesort 原点。
