多字段排序严格从左到右逐级生效，左侧字段值不同时右侧字段不参与比较；字段顺序即业务优先级顺序，每个字段的ASC/DESC须显式声明，NULL需跨库兼容处理。
多字段排序不是“一起排”，而是严格从左到右逐级生效：左边字段值不同时，右边字段根本不会参与比较。顺序写错，SQL 仍能执行，但业务逻辑就悄悄崩了。
ORDER BY 字段顺序 = 业务优先级顺序
比如要查「每个状态里最新的一条记录」，必须写成 ORDER BY status, created_at DESC：先按 status 分大组，每组内再按 created_at 倒序。如果写反成 ORDER BY created_at DESC, status，结果就是所有记录按时间从新到旧排，status 只在时间相同时起作用——完全偏离本意。
- 验证方法：挑几行
status相同的数据，看它们是否真按created_at DESC排 - 字段位置就是优先级：第一个是主依据，第二个只是“同主值时的次级规则”
- 别用数字位置（如
ORDER BY 1, 3 DESC），SELECT列一改，排序就失效
每个字段的 ASC/DESC 必须显式声明
ORDER BY a, b DESC 表示 a ASC, b DESC，不是“整体降序”。漏写方向，就默认是 ASC，极易翻车。
-
ORDER BY name DESC, age→name降序、age升序（很多人误以为逗号后统一生效） - 安全写法：所有字段都显式写方向，如
ORDER BY name DESC, age DESC -
ORDER BY a, b等价于ORDER BY a ASC, b ASC，不是“继承前一个方向”
NULL 值必须显式控制，否则跨库结果不一致
MySQL 默认 NULL 在 ASC 时排最前，PostgreSQL 默认排最后。不显式声明，开发和生产环境排序可能完全不同。
- PostgreSQL 支持
NULLS FIRST/NULLS LAST，必须紧跟在对应排序项后：ORDER BY reviewer_id NULLS FIRST, created_at DESC - MySQL 8.0+ 不支持该语法，可用布尔表达式模拟：
ORDER BY (reviewer_id IS NULL), created_at DESC（FALSE=0在前，TRUE=1在后） - 通用兜底：
ORDER BY CASE WHEN reviewer_id IS NULL THEN 0 ELSE 1 END, created_at DESC
带表达式的 ORDER BY 必须配函数索引，否则性能陡降
含 CASE WHEN、LENGTH() 或计算字段的 ORDER BY 无法走普通 B-tree 索引。高频查询中，响应延迟会随数据量线性上升。
- PostgreSQL 示例：
CREATE INDEX idx_orders_status_time ON orders ((CASE WHEN status = 'pending' THEN 1 ELSE 2 END), created_at DESC) - MySQL 8.0+ 类似，需用函数索引语法：
CREATE INDEX idx_orders_status_time ON orders ((CASE WHEN status = 'pending' THEN 1 ELSE 2 END), created_at DESC) - 用
EXPLAIN看Extra列是否有Using filesort，有就是没走索引排序
最容易被忽略的是：字段语义优先级和物理顺序必须对齐。少一个 DESC、错一位顺序、漏处理 NULL，都可能让分页错位、TOP-N 拿错数据、报表排序颠倒。
