多列排序语法为order by字段1方向,字段2方向，优先级从前到后；每列需显式指定asc/desc；null处理、索引匹配及窗口函数中order by语义易被忽略。
ORDER BY 多列排序的语法结构
多列排序直接在 ORDER BY 后用逗号分隔字段，顺序即优先级：前面的列先排，相同时再按后面的列排。
每列可独立指定方向：ASC（升序，默认）或 DESC（降序），不写方向时统一按升序处理，但建议显式写出避免歧义。
-
ORDER BY status DESC, created_at ASC：先按状态降序（比如 'failed' > 'success'），同状态时再按时间升序（旧的在前） - 不能写成
ORDER BY status DESC, created_at期望后者也自动DESC——后一列没声明方向就是ASC - 字段名若含空格或关键字，需用反引号（MySQL）或双引号（PostgreSQL）包裹，如
ORDER BY `order_id` DESC
NULL 值在多列排序中的实际位置
不同数据库对 NULL 的默认排序行为不一致：MySQL 把 NULL 当作最小值（ASC 时排最前），PostgreSQL 默认当最大值（ASC 时排最后）。这会导致跨库迁移时排序结果突变。
- 显式控制
NULL位置更可靠：用IS NULL或IS NOT NULL配合ORDER BY，例如ORDER BY (updated_at IS NULL) ASC, updated_at DESC—— 先把非空的放前面，再按时间倒序 - PostgreSQL 支持
NULLS FIRST/NULLS LAST，MySQL 8.0+ 也支持，但低版本只能靠表达式模拟 - 如果业务逻辑依赖
NULL排最前，别只测单条数据，要用含NULL和非NULL混合的测试集验证
ORDER BY 多列 + LIMIT 的性能隐患
加 LIMIT 不会减少排序开销：数据库仍需先完成全部排序，再截取前 N 行。尤其当排序字段无索引、或组合索引顺序不匹配时，可能触发 filesort 或临时表，拖慢查询。
- 检查执行计划：MySQL 看
Extra是否含Using filesort；PostgreSQL 看是否出现Sort节点且rows很大 - 索引要覆盖所有
ORDER BY字段，且顺序严格一致，例如ORDER BY category DESC, score ASC对应索引应为(category, score)（注意 MySQL 8.0+ 支持混合方向索引，但老版本只认首字段方向） - 如果只是“取最新几条”，且
created_at有索引，ORDER BY created_at DESC LIMIT 10效率远高于ORDER BY user_id, created_at DESC LIMIT 10（后者大概率无法用上索引）
在窗口函数中复用 ORDER BY 多列逻辑
窗口函数（如 ROW_NUMBER()）的 ORDER BY 子句写法和主查询一致，但语义不同：它只决定当前窗口内的行序，不影响最终结果集顺序。
- 写法一样：
ROW_NUMBER() OVER (ORDER BY dept_id ASC, salary DESC) - 容易忽略的是：窗口
ORDER BY必须是确定性排序，否则同一查询多次执行可能得到不同序号——若salary有重复，需补一个唯一字段（如id）保序：ORDER BY dept_id, salary DESC, id - 别把窗口里的
ORDER BY当成最终输出排序，真要控制结果顺序，外面还得套一层ORDER BY
ORDER BY。动手前先看执行计划，比调半天 SQL 更省时间。
