最稳的方案是用CASE WHEN，所有主流数据库都支持；它通过将每个目标值映射为统一数字序号实现跨库兼容排序，必须显式写ELSE分支（如ELSE 999）以避免NULL干扰，且返回值类型须一致，多级排序用逗号分隔表达式，末尾应补唯一字段确保稳定性。
最稳的方案是用 CASE WHEN，所有主流数据库都支持；如果只跑 MySQL，FIELD() 更简洁但不可移植。
用 CASE WHEN 实现跨数据库兼容的自定义排序
核心是把每个目标值映射成一个数字序号，数据库按这个数字升序排。它不依赖任何扩展函数，MySQL、PostgreSQL、SQL Server、Oracle、SQLite 全部原生支持。
- 必须写
ELSE分支：没匹配上的行（比如 NULL 或未知状态）会变成NULL，而不同数据库对NULL在排序中的位置处理不一致（MySQL 默认排最后，PostgreSQL 默认排最前），加ELSE 999能统一控制位置 - 字段名和值要严格匹配：大小写、空格、前后缀都不能错，
LOWER(status)可提前归一化 - 多级排序直接逗号拼接：比如先按优先级，再按时间倒序，写成
ORDER BY CASE status WHEN 'urgent' THEN 1 ELSE 2 END, created_at DESC，别试图在一个CASE里硬凑复合值 - 返回值类型必须一致：不能
WHEN 'a' THEN 1 ELSE '99'，字符串和数字混用可能触发隐式转换或报错
MySQL 专用：FIELD() 函数怎么用才不出错
FIELD() 是 MySQL 和 MariaDB 独有的快捷写法，语义清晰，但行为细节容易踩坑。
- 参数顺序 = 排序优先级：
FIELD(status, 'draft', 'review', 'published')表示'draft'排第一，'published'排第三 - 未匹配值和
NULL全部返回0，默认排最前——这常导致结果开头突然冒出一堆“其他”数据，要用WHERE status IN ('draft','review','published')过滤，或用COALESCE(FIELD(...), 999)拉到最后 - 别在
ORDER BY里混用FIELD()和其它字段做“全局二级排序”：例如ORDER BY FIELD(id, 101,105,103), updated_at DESC的实际效果是“先分组再组内排序”，不是你想象的“整个列表按 ID 序列排，再整体按时间重排” - 值列表超过 20 个时性能明显下降，因为每次都要线性扫描比对；此时应切回
CASE WHEN或建映射表
排序逻辑变复杂了，该不该建映射表？
当顺序不再固定（比如运营后台可拖拽调整品类权重）、或枚举值太多（如 50+ 个地区）、或需要复用到多个查询时，硬编码 CASE 或 FIELD() 就难维护了。
- 建一张小表，比如
sort_order，含key_name和weight两列，插入业务认可的顺序 -
JOIN时用LEFT JOIN防止丢数据，但记得COALESCE(o.weight, 999)处理未映射项，否则NULL权重会让这些行挤在最前面 - 给
key_name加唯一索引，关联速度才快；如果映射表本身也频繁更新，注意事务隔离级别，避免查到中间态 - 这种方案天然支持运行时改顺序——改表就行，SQL 不动，适合中大型系统
真正容易被忽略的是：自定义排序本身不保证稳定性。如果两个记录的排序键完全相同（比如 CASE 返回一样的数字，或 FIELD() 匹配到同一位置），数据库可能任意打乱它们的相对顺序，分页时就可能重复或漏掉数据。稳妥做法是在 ORDER BY 最后补一个唯一字段，比如 id 或 created_at。
