MySQL 5.7及更早版本不支持混合ASC/DESC索引扫描，建INDEX (a, b)后执行ORDER BY a ASC, b DESC会触发Using filesort；MySQL 8.0+要求索引定义与ORDER BY逐字段方向严格一致，且范围查询后字段无法参与排序。
MySQL 5.7 及更早版本不支持混合 ASC/DESC 索引扫描
如果你在 MySQL 5.7 或之前版本中建了 INDEX (a, b)（默认全 ASC），然后执行 ORDER BY a ASC, b DESC，MySQL 无法复用该索引完成排序——它只能对整个索引做正向或反向遍历，但不能让一个字段正向、另一个反向。结果就是直接触发 Using filesort。
即使你显式写了 CREATE INDEX idx ON t(a ASC, b DESC)，5.7 也会忽略 DESC 声明，实际存储仍是 (a ASC, b ASC)。所以所谓“混合方向”在 5.7 根本不存在，不是配置问题，是能力缺失。
MySQL 8.0+ 要求索引定义与 ORDER BY 完全方向一致
8.0.12+ 支持降序索引，但前提是：索引定义中必须明确写出方向，且查询中的 ORDER BY 子句必须逐字段、逐方向完全匹配。
-
INDEX (a ASC, b DESC)→ 只能用于ORDER BY a ASC, b DESC -
ORDER BY a DESC, b DESC不行（a 方向不匹配） -
ORDER BY a ASC, b ASC也不行（b 方向不匹配） - 哪怕只差一个字段的方向，优化器就放弃索引排序，回落到
Using filesort
注意：ORDER BY a, b DESC 这种省略 ASC 的写法，在 8.0+ 中会被解析为 a ASC, b DESC，所以索引也必须是 (a ASC, b DESC) 才生效。
WHERE 条件含范围查询时，后续字段无法参与排序
即使你建了 INDEX (a, b DESC, c)，若查询是：
SELECT * FROM t WHERE a > 10 ORDER BY b DESC, c;
那么 b DESC, c 就无法利用索引顺序。因为 a > 10 是范围条件，B+ 树中满足该条件的 a 值对应多个子树分支，每个分支内 b, c 虽有序，但跨分支后整体无序——MySQL 无法保证最终输出按 b DESC, c 全局有序。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
只有等值条件（=、IN 单值列表）才能“锁定”索引的一个连续片段，让后续字段的有序性生效。
函数、表达式或隐式转换会直接切断索引排序链
只要 ORDER BY 里出现任何计算，索引就彻底失效：
-
ORDER BY UPPER(name)→ 字符串函数，索引值 ≠ 计算值 -
ORDER BY created_at + INTERVAL 1 DAY→ 表达式，无法映射到索引键 -
ORDER BY status = 'active'→ 布尔表达式，无序可言 -
WHERE id = '123' ORDER BY created_at→ 若id是整型，字符串比较触发隐式转换，可能导致整个联合索引失效
这类写法不会报错，但 EXPLAIN 中一定出现 Using filesort，且优化器通常连尝试走索引排序的念头都没有。
真正容易被忽略的是：ASC/DESC 匹配不是“语义等价”，而是字面级严格一致；而范围条件对排序能力的破坏，往往比它对 WHERE 过滤的影响更隐蔽——你可能看到 key 列有值、rows 很小，却仍逃不掉 Using filesort。
