order by 多列排序必须用逗号分隔且严格按从左到右优先级逐级生效：先按首列排序，值相同时才比较次列；每列方向需显式声明asc/desc，默认asc；顺序写反或漏写方向将导致分组逻辑失效。
ORDER BY 多列排序必须用逗号分隔，顺序决定优先级，写反了就完全达不到分组内再排序的效果。
ORDER BY 后多个字段怎么写才对
直接在 ORDER BY 后面列出字段名，用英文逗号分隔，每个字段可独立加 ASC 或 DESC。数据库严格从左到右逐级处理：先排第一列，值相同时才看第二列，依此类推。
常见错误包括：
- 把逻辑顺序搞反，比如想“同一部门内按薪资从高到低”，却写成
ORDER BY salary DESC, department ASC——这会导致不同部门的高薪员工被混排在一起 - 漏写排序方向，误以为所有列都按同一方向排；其实每列方向需显式声明，不写默认是
ASC - 在
SELECT DISTINCT或UNION查询中用了不在选择列表里的字段排序，会报错
NULL 值和重复值怎么处理
不同数据库对 NULL 的默认排序行为不一致：MySQL 和 PostgreSQL 默认把 NULL 当最小值（ASC 时排最前），SQL Server 和 Oracle 则可能当最大值。一旦业务要求明确，就得显式控制：
- 用
NULLS FIRST或NULLS LAST（PostgreSQL、Oracle 支持；MySQL 不支持，得用IS NULL配合CASE） - 遇到多列值全相同的情况（如部门+薪资都一样），数据库不保证稳定顺序，除非加第三列（比如
id）兜底 - 如果排序字段含函数或表达式（如
UPPER(name)），记得在对应列上建函数索引，否则容易触发filesort
能不能用别名或位置编号排序
可以用别名，但要注意作用域限制；位置编号（如 ORDER BY 2）语法虽合法，但极易出错：
- 别名只在当前查询有效，且不能用于子查询的外层
ORDER BY（排序结果不保留） - 位置编号在
SELECT列表变动后会指向错误字段，调试困难，团队协作中基本等于埋雷 - 涉及
CASE WHEN排序时，所有分支返回类型必须一致，且建议显式写ELSE，避免隐式类型转换导致排序异常
真正难的不是语法，而是理解“逐级”这个机制——它不像 Excel 多条件排序那样直观可视化，一列写错，整个分组逻辑就垮了。
