ORDER BY 多字段的标准写法是用逗号分隔字段，从左到右逐级排序：先按第一个字段排序，值相同时再按第二个字段排序，依此类推；每个字段后可加 ASC（默认可省略）或必须显式写出 DESC。
直接结论：在 ORDER BY 后用逗号分隔多个字段，数据库会从左到右逐级排序 —— 先按第一个字段排，相同值再看第二个，依此类推。
ORDER BY 多字段语法怎么写？
标准写法就是把字段名挨个列出来，用逗号连接，每个字段后可选加 ASC 或 DESC：
SELECT name, department, salary FROM employees ORDER BY department ASC, salary DESC;
注意点：
-
ASC可省略（默认就是升序），但DESC必须显式写出 - 字段顺序决定优先级，
department在前，salary在后，不能颠倒 - 别名可用，比如
SELECT salary AS pay ORDER BY pay DESC是合法的 - 不支持多个
ORDER BY子句，只允许一个，里面写多个字段
为什么相同字段值时排序结果不稳定？
当多级排序到最后一个字段仍有重复值（比如部门和薪资都一样），数据库不会继续比较，而是保留原始物理顺序 —— 这不是 bug，是 SQL 标准行为。实际表现为：
- 两次查询返回行顺序可能不同（尤其在并发或数据变动后）
- 分页时同一页内容可能跳变
- 测试环境和生产环境排序看起来“不一致”
解决办法很简单：加一个唯一字段兜底，比如主键或时间戳：
ORDER BY department ASC, salary DESC, id ASC
NULL 值在多字段排序里总排错位置怎么办？
不同数据库对 NULL 的默认处理不一致：
- MySQL 默认
NULLS FIRST（升序时排最前） - PostgreSQL 默认
NULLS LAST（升序时排最后）
这意味着同一段 SQL 在不同环境执行，排序结果可能完全相反。关键原则：
- 只要字段可能为
NULL，就必须显式声明NULLS FIRST或NULLS LAST - 这个修饰符只作用于紧邻它的那个排序项，不能写在整条
ORDER BY末尾 - 错误写法：
ORDER BY status, created_at DESC NULLS LAST→NULLS LAST只修饰created_at DESC，不影响status - 正确写法：
ORDER BY status NULLS LAST, created_at DESC NULLS LAST
多字段排序性能差，是不是没走索引？
复合索引是否生效，取决于 ORDER BY 字段顺序和索引定义是否匹配：
- 如果建了索引
(department, salary)，那么ORDER BY department ASC, salary DESC可以用上（注意：MySQL 8.0+ 支持混合方向索引，旧版本要求全部同向） - 但
ORDER BY salary DESC, department ASC就无法利用该索引，会触发filesort - WHERE 条件里的字段也得参与考虑：索引
(status, department, salary)，若查询带WHERE status = 'active'，再ORDER BY department, salary才能高效 - 避免在排序字段上用函数，比如
ORDER BY UPPER(name)会强制排序，无法走索引
真正容易被忽略的是：字段顺序、方向一致性、WHERE 与 ORDER BY 的协同 —— 这三点缺一不可，否则索引形同虚设。
