CASE WHEN 是最通用、跨数据库兼容的排序权重实现方式，需覆盖所有值并显式指定ELSE分支，返回类型须统一，且无法利用索引，大数据量时应物化排序字段。
直接用 CASE WHEN 在 ORDER BY 里写排序权重，是最通用、跨数据库兼容的做法。别指望 FIELD() 或 DECODE() 能通吃所有环境——MySQL 有 FIELD()，Oracle 用 DECODE()，PostgreSQL 和 SQL Server 只认 CASE WHEN。
用 CASE WHEN 实现字段值优先级排序
当你要把 status 字段按 “提交→审核→完成” 的业务顺序排，而不是字母或字典序时，CASE WHEN 是唯一稳妥选择。它本质是给每行生成一个临时排序键，再按这个键排序。
- 必须把所有可能值都覆盖，否则未匹配的行会被排在最前（因为
CASE默认返回NULL，而多数数据库中NULL在ASC下排最前） - 推荐显式补上
ELSE分支，比如设为999，避免隐式NULL干扰顺序 - 数值越小，优先级越高；不要用字符串拼接或负号 trick，容易和后续时间字段排序冲突
示例：ORDER BY CASE WHEN status = 'Apply' THEN 0 WHEN status = 'Review' THEN 1 WHEN status = 'Finish' THEN 2 ELSE 999 END
多条件动态排序：状态内再按不同字段排序
业务常要求“状态为提交的按创建时间倒序，状态为审核的按开始时间正序”，这时不能只靠一个 CASE，得嵌套第二层逻辑。
- 每个
WHEN分支里只能返回一种可比类型，比如全转成SIGNED或全转成DATE；混用UNIX_TIMESTAMP()和id会导致隐式类型转换失败 - 注意 PostgreSQL/SQL Server 不支持在
ORDER BY里对表达式直接加DESC，要写成CASE ... END DESC，而不是CASE ... END后单独跟DESC - 如果某状态没有对应时间字段（比如
rejected_time为NULL），建议用COALESCE(t.rejected_time, '1970-01-01')填充，否则该行可能被挤到开头或结尾
示例：ORDER BY CASE WHEN status = 'Apply' THEN -UNIX_TIMESTAMP(create_time) WHEN status = 'Review' THEN UNIX_TIMESTAMP(start_time) ELSE 0 END
性能与索引失效风险
CASE WHEN 排序无法走索引，这是硬伤。哪怕你在 status 上建了索引，只要 ORDER BY 里出现表达式，优化器大概率触发 filesort。
- 数据量小于 10 万行，影响不明显；超过百万行，务必考虑提前物化排序字段（比如加一列
sort_priority并维护） - 别在
CASE里调用函数如NOW()、UUID()，会导致每行重算，且无法复用执行计划 - 如果只是偶尔需要这种排序，比聚合查询还少，那不如在应用层用
List.sort()处理，数据库只负责查，别让它背锅
真正容易被忽略的是：CASE WHEN 返回值类型必须一致，否则某些数据库（如 SQL Server）会报错或静默截断。别以为写个 THEN 1 和 THEN 'abc' 还能自动转，它不会帮你猜。要么全数字，要么全字符串，要么显式 CAST。这点在跨库迁移或 ORM 拼 SQL 时特别坑。
