MySQL的ORDER BY多字段排序严格按书写顺序逐级生效：先按首字段排序，相等时再按次字段排序，以此类推；各字段方向需显式声明，NULL默认最小，索引利用要求字段顺序和方向与索引定义完全一致。
ORDER BY 后多个字段的执行顺序怎么理解
MySQL 的 ORDER BY 多字段排序是严格按书写顺序生效的：先按第一个字段排，相等时再按第二个字段排，以此类推。它不是“同时比较所有字段”，而是逐级分流——就像图书馆先按分类号排，同类书再按作者姓氏排，同作者再按出版年份排。
常见误解是认为 ORDER BY a, b 等价于“a 和 b 综合打分排序”，实际完全不是。只要 a 值不同，b 就根本不会参与比较。
ASC/DESC 只作用于紧邻的字段，不能省略或跨字段继承
每个排序字段必须显式声明方向，ASC 或 DESC 不会自动延续到下一个字段。写成 ORDER BY name DESC, age 时，age 默认是 ASC，不是 DESC；写成 ORDER BY name, age DESC 也不代表 name 是 ASC（虽然默认确实是），但靠默认值容易出错。
-
ORDER BY status DESC, created_at DESC, id ASC—— 明确、安全 -
ORDER BY status DESC, created_at, id——created_at和id都是ASC，但靠默认值，可读性差，易被后续修改破坏 -
ORDER BY status DESC, created_at DESC id ASC—— 语法错误，id前缺逗号
NULL 值在多字段排序中的实际位置
MySQL 默认把 NULL 当作最小值（ASC 时排最前，DESC 时排最后），这个规则对每个字段独立生效。比如 ORDER BY a ASC, b DESC 中，所有 a IS NULL 的行会先被聚在一起（因为 a 最小），这部分内部再按 b 降序排。
如果业务要求 NULL 排最后（哪怕 ASC），得用 IS NULL 手动控制：
ORDER BY (a IS NULL) ASC, a ASC, (b IS NULL) ASC, b DESC
这样 a IS NULL 返回 1，非 NULL 返回 0，ASC 就让非 NULL 先出现。
性能影响：多字段排序可能让索引失效
只有当 ORDER BY 字段顺序和索引定义顺序**完全一致**，且所有字段都使用相同方向（或都是 ASC，因 MySQL 5.7+ 支持反向扫描但有代价），才可能走索引排序。例如有联合索引 INDEX idx_status_created (status, created_at)：
-
ORDER BY status, created_at—— 可走索引 -
ORDER BY status DESC, created_at DESC—— 可走索引（5.7+） -
ORDER BY status ASC, created_at DESC—— 无法利用该索引排序，触发 filesort -
ORDER BY created_at, status—— 字段顺序不匹配，无法利用
用 EXPLAIN 看 Extra 列是否含 Using filesort 是最快判断方式。
多字段排序本身不慢，但一旦掉出索引覆盖范围，数据量大时 filesort 会显著拖慢响应——尤其当结果集要取前 N 行却得先全量排序时。
