MySQL的ORDER BY多字段排序严格按书写顺序逐级生效：先按首字段排序，相等时再按次字段排序；各字段方向需显式声明，NULL默认最小，索引利用要求字段顺序和方向与索引定义完全一致。
MySQL 的 ORDER BY 多字段排序不是“一起比大小”，而是严格从左到右逐级判定：只有左侧字段值完全相等的行，才会进入右侧字段的比较。理解这点，才能写出逻辑正确的排序语句，否则结果看似正常，实则业务逻辑已悄悄错位。
ORDER BY a, b DESC 的真实含义是什么
这个写法中，a 是升序（默认 ASC），b 是降序——DESC 只作用于紧邻的 b，不会“传染”给 a，也不会继承到后续字段。
- 错误认知：“
a, b DESC” 表示两个都降序 → 实际a是升序 - 漏写逗号：
ORDER BY a DESC b DESC→ 直接报错ERROR 1064 - 依赖默认方向：
ORDER BY status DESC, created_at, id→created_at和id都是ASC，但靠默认值易被误读或后续改坏 - 推荐写法：
ORDER BY status DESC, created_at DESC, id ASC—— 每个方向显式声明，无歧义
NULL 值在多字段排序中到底排在哪
MySQL 默认把 NULL 当作最小值：升序时排最前，降序时排最后。这个规则对每个字段独立生效，且影响分组内的相对位置。
-
ORDER BY category_id ASC, sort_order ASC中：所有category_id IS NULL的行先被聚在最前面，这部分内部再按sort_order升序排 - 想让
NULL统一排最后？MySQL 8.0+ 可用NULLS LAST：ORDER BY category_id ASC NULLS LAST, sort_order ASC NULLS LAST - 兼容旧版本（如 5.7）需手动控制：
ORDER BY (category_id IS NULL) ASC, category_id ASC—— 利用布尔表达式返回 0/1 来翻转优先级
为什么加了索引，ORDER BY 还很慢
多字段排序能否走索引，取决于 ORDER BY 字段顺序、方向是否与联合索引定义**完全一致**。不匹配就会触发 filesort，数据量大时性能断崖下跌。
- 假设有索引
INDEX idx_status_created (status, created_at)： -
ORDER BY status, created_at→ 可走索引 -
ORDER BY status DESC, created_at DESC→ MySQL 5.7+ 支持反向扫描，可走 -
ORDER BY status ASC, created_at DESC→ 方向不一致，无法利用该索引排序 -
ORDER BY created_at, status→ 字段顺序颠倒，索引失效 - 验证方式：
EXPLAIN SELECT ... ORDER BY ...，看Extra列是否含Using filesort
最容易被忽略的是：多字段排序的“优先级嵌套”特性无法被直觉感知，出错时 SQL 仍能执行、结果也“看起来合理”，但分页、排名、分组取 Top N 等场景会悄然错乱。务必在测试数据中刻意构造重复字段值 + NULL 组合，验证排序行为是否符合业务预期。
