ORDER BY中用CASE WHEN可实现多条件优先级排序，先按状态分组再组内按时间倒序；需确保各分支返回同类型值、必须写ELSE、注意NULL处理及数据库兼容性。
ORDER BY 里直接写 CASE WHEN 能实现多条件优先级排序
当需要按「先按状态分组，再在每组内按时间倒序」这类逻辑排序时，CASE WHEN 是最直接的解法。它让数据库在排序阶段就完成条件判断，不依赖应用层二次处理。
常见错误是把 CASE WHEN 写成子查询或嵌套 SELECT —— 这不仅慢，还可能因 GROUP BY 或聚合字段缺失报错 ERROR: column "xxx" must appear in the GROUP BY clause。
- 每个
WHEN分支返回相同类型值（比如都返回INT），否则 PostgreSQL 会报column "case" has type integer but expression has type text - 别漏写
ELSE：没匹配到的行会被排在最前（NULL 默认最小），常导致「已关闭」订单意外出现在列表顶部 - MySQL 8.0+ 和 PostgreSQL 支持在
ORDER BY中用列别名，但 SQLite 和旧版 MySQL 不支持，建议直接复写表达式
用 NULLS FIRST / NULLS LAST 控制空值位置
当排序字段含 NULL（如未填「审核人」的记录），默认行为因数据库而异：PostgreSQL 把 NULL 当最大值，MySQL 当最小值。不显式声明会导致线上环境排序结果不一致。
例如要让「待审核」（reviewer_id IS NULL）排在最前面，且不影响后续时间排序：
ORDER BY CASE WHEN reviewer_id IS NULL THEN 0 ELSE 1 END, created_at DESC NULLS LAST
注意：NULLS FIRST 必须紧跟在对应排序字段后，不能写成 ORDER BY field NULLS FIRST, other_field 后再加全局修饰。
多个字段组合排序时，避免隐式类型转换踩坑
混合字符串和数字字段排序（比如按「优先级等级」+「ID」）容易触发隐式转换。例如 ORDER BY priority_level, id，若 priority_level 是 VARCHAR 存着 'high'、'low'，数据库会按字典序排，'high' 反而比 'low' 小。
- 用
CASE WHEN priority_level = 'high' THEN 1 ...显式映射为整数 - 字符串字段参与多级排序时，加
::TEXT（PostgreSQL）或CAST(... AS CHAR)（MySQL）确保类型稳定 - 时间字段混用
TIMESTAMP和DATE类型时，ORDER BY updated_at, created_date可能因精度差异导致同秒内顺序不可预期
性能敏感场景下，表达式排序必须配函数索引
带 CASE WHEN 或计算字段的 ORDER BY 无法走普通 B-tree 索引。如果该排序出现在高频查询中（如后台订单列表），响应延迟会随数据量陡增。
PostgreSQL 示例（MySQL 8.0+ 类似）：
CREATE INDEX idx_orders_sort_state_time
ON orders (
CASE WHEN status = 'shipped' THEN 1
WHEN status = 'pending' THEN 2
ELSE 3 END,
created_at DESC
);
注意：函数索引的表达式必须和 ORDER BY 中完全一致（包括括号、空格），少一个空格就会失效；另外，WHERE 条件中若用了不同状态枚举，索引覆盖范围可能受限。
复杂点在于，业务逻辑一变（比如新增 'cancelled' 状态），索引和所有相关 SQL 都得同步改——这种耦合容易被忽略，上线后才发现排序变慢却查不出原因。
