ORDER BY 多列排序需用逗号分隔各字段，每列独立指定ASC或DESC（默认ASC），按从左到右优先级逐级排序；常见错误是误以为ORDER BY a, b DESC中a也降序，实际a为升序。
ORDER BY 多列排序的语法结构怎么写
多列排序不是简单堆砌字段，而是用逗号分隔各列，并为每列单独指定 ASC 或 DESC；不显式声明时默认是 ASC，但混用升降序时必须写清楚，否则容易误以为整条语句按同一方向排。
常见错误是写成 ORDER BY col1, col2 DESC——这实际等价于 ORDER BY col1 ASC, col2 DESC，但很多人误以为 col1 也被 DESC 了。正确写法要明确： ORDER BY col1 DESC, col2 ASC。
- 每列的排序方向只作用于该列，不影响前/后列
- 数据库按从左到右顺序逐列比较：先比
col1，相等再比col2，以此类推 - NULL 值在大多数数据库中默认排在最前（
ASC）或最后（DESC），行为可能因引擎而异（如 PostgreSQL 和 MySQL 对 NULL 的默认位置不同）
MySQL 和 PostgreSQL 中 DESC/ASC 的兼容性差异
语法层面两者都支持 ASC/DESC，但对 NULL 的处理逻辑有隐含区别：MySQL 默认把 NULL 当作“最小值”，所以 ORDER BY col DESC 会让 NULL 排末尾；PostgreSQL 默认把 NULL 当作“最大值”，ORDER BY col DESC 时 NULL 反而在最前。
如果业务依赖确定的 NULL 位置，不能靠默认行为，得显式控制：ORDER BY col DESC NULLS LAST（PostgreSQL 支持），但 MySQL 不支持 NULLS LAST 语法，得用 IS NULL 补丁：
ORDER BY (col IS NULL) ASC, col DESC
这条语句强制把非 NULL 值排前面，再对它们按 col 降序。
性能影响：多列 ORDER BY 能否走索引
只有当 ORDER BY 的列顺序和索引定义顺序完全一致，且方向匹配（或全为 ASC）时，才可能用上索引避免文件排序（Using filesort）。
- 有复合索引
INDEX (a, b, c)，则ORDER BY a, b或ORDER BY a ASC, b ASC可走索引 -
ORDER BY a DESC, b ASC在 MySQL 8.0+ 支持降序索引的前提下才可能命中；老版本会退化为文件排序 -
ORDER BY b, a无法利用(a, b, c)索引，因为跳过了首列a
执行前务必用 EXPLAIN 看 Extra 列是否含 Using filesort。
实际场景中容易被忽略的排序稳定性问题
SQL 标准不保证相同排序键下的行物理顺序，也就是说：ORDER BY status 返回的“已完成”记录之间，谁在前谁在后是不确定的——除非你补上第二级排序依据，比如主键：ORDER BY status, id。
这在分页（LIMIT/OFFSET）或前端列表渲染时特别关键：两次查同一页，若没加稳定键，可能漏数据或重复显示。
另外，字符集也会影响结果，比如 utf8mb4_0900_as_cs 和 utf8mb4_general_ci 对大小写和重音的处理不同，导致 ORDER BY name 排序结果不一致。
