mysql 8.0+支持混合方向索引，但order by必须与索引逐列方向严格一致（如index(a asc, b desc)仅加速order by a asc, b desc），方向错一位或不满足最左前缀即触发using filesort。
ORDER BY多字段混合排序为什么容易失效
MySQL对ORDER BY a ASC, b DESC这类混合方向排序的支持，高度依赖版本和索引定义。在MySQL 8.0之前，联合索引只支持统一升序或统一降序（如INDEX(a, b)只能加速ORDER BY a ASC, b ASC或ORDER BY a DESC, b DESC），一旦方向不一致，就直接退化为Using filesort。即使WHERE条件能走索引，排序部分仍可能无法复用——因为排序方向不匹配，优化器判定“索引不能提供有序输出”。
MySQL 8.0+如何建混合方向索引
从8.0开始支持显式声明列的排序方向，这是解决混合排序的关键。必须用CREATE INDEX明确写出方向，不能依赖默认：
CREATE INDEX idx_user_status_created ON orders (user_id, status ASC, created_at DESC);
这个索引能高效支撑以下查询：
SELECT * FROM orders WHERE user_id = 123 ORDER BY status ASC, created_at DESC-
SELECT status, created_at FROM orders WHERE user_id = 123 ORDER BY status ASC, created_at DESC（覆盖索引）
但注意：ORDER BY status DESC, created_at ASC依然无法使用该索引；ORDER BY created_at DESC单独使用也不行——不满足最左前缀。
老版本（
没有降序索引支持时，强行让混合排序走索引几乎不可行。常见误操作是建INDEX(a, b)然后指望ORDER BY a ASC, b DESC生效，结果仍是Using filesort。可行路径只有两条：
- 改写业务逻辑：统一排序方向（如全转为ASC，再在应用层翻转部分字段展示）
- 用覆盖索引 + 小结果集兜底：建
INDEX(user_id, status, created_at)，只查必要字段（避免SELECT *），控制LIMIT偏移量（如不超过1000行），靠内存排序扛住 - 放弃索引排序，调大
sort_buffer_size，减少磁盘filesort概率（仅适用于读多写少、并发不高的场景）
验证索引是否真被用于排序
别信猜测，只看EXPLAIN的Extra字段：
- 出现
Using filesort→ 排序没走索引，正在额外排序 - 没出现
Using filesort，且key显示用了你的索引 → 成功 - 没
Using filesort但key是NULL→ 可能走了主键聚簇索引顺序返回，不算优化
特别注意：如果SELECT *但索引只含部分字段，优化器可能主动弃用索引——因为回表代价高于全表扫描+排序。这时应优先考虑覆盖索引（把常用查询字段全加进索引），而不是盲目扩大索引宽度。
混合方向排序的索引设计，本质是让索引结构与查询意图严格对齐。最容易被忽略的不是语法怎么写，而是忘记检查EXPLAIN里Extra的真实值——它不会说谎，但很多人根本没看。
