MySQL 8.0+ 才真正支持混合 ASC/DESC 索引排序；5.7 及更早版本不支持，ORDER BY age ASC, name DESC 即使建了 (age, name) 索引也大概率触发 Using filesort，因索引仅按默认升序物理有序，无法满足反向扫描需求。
MySQL 8.0+ 才真正支持混合 ASC/DESC 索引排序
在 MySQL 8.0 之前，ORDER BY age ASC, name DESC 即使建了 (age, name) 索引，也大概率触发 Using filesort。因为老版本索引只按定义方向（默认全 ASC）物理有序，无法同时满足反向扫描。8.0 引入降序索引（descending index），允许显式声明列排序方向，这才让混合排序能走索引。
常见错误现象：EXPLAIN 显示 Using filesort，但 WHERE 条件明明命中了索引；或者排序结果正确，但慢查询日志里 Sort_merge_passes 飙高。
- 必须用
CREATE INDEX显式指定方向，如CREATE INDEX idx_age_name_desc ON users (age ASC, name DESC) - 索引方向必须与
ORDER BY字段顺序和方向完全一致——不能颠倒顺序，也不能漏写方向 - 如果查询是
ORDER BY name DESC, age ASC，就得另建(name DESC, age ASC)索引，旧索引不复用 - 5.7 及更早版本无论怎么建索引，只要出现混合方向，基本都 fallback 到 filesort
WHERE + 混合 ORDER BY 的联合索引设计优先级
当查询含 WHERE 和混合 ORDER BY，比如 SELECT * FROM orders WHERE status = 1 ORDER BY create_time DESC, id ASC，索引设计不是简单拼接字段，而是分层考虑：
- 第一层：WHERE 中的等值条件字段放最左，例如
status是等值过滤，必须打头 - 第二层：混合排序字段紧随其后，且严格按
ORDER BY的顺序和方向排列，即create_time DESC, id ASC - 最终推荐索引：
CREATE INDEX idx_status_ctime_id ON orders (status, create_time DESC, id ASC) - 若还涉及
SELECT字段较多，可扩展为覆盖索引，如加user_id、amount等高频返回字段，减少回表
低版本 MySQL（
没法用降序索引，又必须支持混合排序时，实际中常用两种绕过方式，各有适用边界：
- 改写查询逻辑：把
DESC字段转成负值或时间取反，例如ORDER BY -score或ORDER BY UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(created_at)，再配(status, score)或(status, created_at)正向索引——但注意函数会阻止索引用于排序，仅适用于字段本身可数学反转的场景 - 拆成两个单向排序 + 应用层合并：例如先查
DESC最新 100 条，再查ASC最小 100 条，内存里归并；适合分页深度不大、数据量可控的管理后台类查询 - 接受 filesort，但压降开销：调大
sort_buffer_size（每个连接独占）、限制LIMIT、避免SELECT *，让排序尽量在内存完成
最容易被忽略的细节：索引方向声明只对 ORDER BY 有效，不影响 WHERE
很多人以为 CREATE INDEX idx (a DESC, b ASC) 能让 WHERE a > 10 AND b = 5 更快，其实不会——InnoDB 的 B+ 树叶子节点仍是按定义顺序物理存储，但范围查询（如 a > 10）仍从第一个满足条件的键开始正向遍历，DESC 声明不改变查找路径，只影响排序阶段的扫描方向。
换句话说：索引方向只在 ORDER BY 匹配时起效；WHERE 条件是否高效，取决于最左前缀匹配和等值/范围类型，与 ASC/DESC 无关。别为了“看起来整齐”而乱加方向声明，徒增维护成本。
