最稳妥的ORDER BY自定义排序方法是用CASE WHEN将字符串映射为统一整数序号，并强制指定ELSE分支（如ELSE 999），再配合多级排序和末尾唯一字段（如id ASC）确保分页稳定。
ORDER BY里直接用CASE WHEN构造排序权重
想让结果按你指定的字符串顺序排，比如'urgent'在最前、'normal'居中、'low'垫底，最稳妥的办法就是在ORDER BY里用CASE WHEN把每个值映射成一个数字，数据库按这个数字升序排。
本质不是“写条件”，而是“造序号”——返回值必须是可比较的同类型数据，推荐全用整数。
- 每个
WHEN分支后跟THEN一个明确数字，别混用1和'2' - 必须写
ELSE分支，否则没匹配上的行会变成NULL，而NULL在不同数据库排序位置不一致（PostgreSQL默认排最后，MySQL可能排最前） - 示例：
ORDER BY CASE priority WHEN 'urgent' THEN 1 WHEN 'normal' THEN 2 WHEN 'low' THEN 3 ELSE 4 END
多级排序时CASE WHEN只管第一层逻辑
当既要按自定义优先级分组，又要在组内按时间倒序，别试图在一个CASE里拼复合值（比如priority * 10000 + UNIX_TIMESTAMP(created_at)），容易溢出、难维护、还不可读。
ORDER BY支持逗号分隔多个表达式，各负其责才是正解。
- 第一级：用
CASE WHEN控制主顺序，如CASE status WHEN '待支付' THEN 1 ... END - 第二级：直接接普通字段+方向，如
created_at DESC - 如果第二级也要自定义（比如同状态按部门名特定顺序），那就再独立写一个
CASE WHEN，不要塞进第一个里 - 示例：
ORDER BY CASE status WHEN '待支付' THEN 1 WHEN '已支付' THEN 2 ELSE 3 END, created_at DESC
ELSE分支怎么写影响结果稳定性
ELSE不只是兜底，它直接影响分页是否重复、列表是否跳变。常见错误是写成ELSE NULL或干脆省略。
更麻烦的是，有人想让未列出的值“按原字段自然排序”，于是写ELSE priority——这会导致类型不一致（前面是整数，后面是字符串），某些数据库（如PostgreSQL）会报错，MySQL可能隐式转换但排序错乱。
- 安全做法：统一用整数，比如
ELSE 999，把未知项集中排在末尾 - 若真要混合排序（已知项手排+未知项自然排），得拆成两个
ORDER BY项：CASE WHEN ... END, priority，但要注意priority字段本身是否允许NULL - 分页场景下，强烈建议在最后补一个唯一字段，如
id ASC，避免相同权重值导致行序不稳定
不同数据库对CASE WHEN在ORDER BY中的兼容性
MySQL、PostgreSQL、SQL Server都完全支持CASE WHEN出现在ORDER BY中，语法一致；SQLite也支持，但要求ELSE不可省略，否则报错。
另外注意：有些旧版SQL Server（2005以前）对CASE嵌套深度有限制，不过现在基本不用考虑。
- 别用
ORDER BY 2这种列序号写法去替代CASE WHEN，它们语义完全不同 - 函数如
FIELD()（MySQL特有）或POSITION()也能实现类似效果，但跨库能力差，不如CASE WHEN通用 - 如果排序逻辑极复杂且高频使用，可考虑建计算列或物化视图预处理，而不是每次查都算一遍
CASE
实际用的时候，最容易被忽略的是最后一级稳定排序——哪怕所有CASE分支返回值都不同，只要表里存在并发写入或索引不覆盖，id之类唯一字段没显式写进ORDER BY，分页就可能漏数据或重复。
