最稳的选择是CASE WHEN实现自定义排序，所有主流数据库均支持；需注意字段名正确、补全ELSE分支、处理NULL和大小写敏感问题。
ORDER BY CASE WHEN 实现自定义排序
SQL 标准不支持直接传入一个顺序数组来排序，但用 CASE WHEN 可以明确为每个目标值指定优先级。这是最通用、兼容性最好的方案，所有主流数据库（MySQL、PostgreSQL、SQL Server、Oracle）都支持。
常见错误是把字段名写错，或漏掉 ELSE 分支——没匹配上的行会被排在最前面（PostgreSQL）或最后（MySQL），行为不一致，容易出 bug。
- 按产品状态
'draft'→'review'→'published'顺序排：ORDER BY CASE status WHEN 'draft' THEN 1 WHEN 'review' THEN 2 WHEN 'published' THEN 3 ELSE 4 END
- 字符串比较要严格，
'Draft'和'draft'是不同值；大小写敏感时建议先统一用LOWER(status) - 如果排序字段可能为
NULL，CASE中需单独处理WHEN status IS NULL THEN ...，否则这些行会归入ELSE
MySQL 的 FIELD() 函数更简洁
MySQL 提供了 FIELD() 函数，语法短、可读性强，适合简单场景。但它只在 MySQL 和 MariaDB 中可用，跨数据库迁移时必须重写。
典型误用是把字段名和值顺序搞反：第一个参数是列名，后面才是期望的值序列，顺序即排序优先级。
- 按城市名自定义顺序：
ORDER BY FIELD(city, 'Beijing', 'Shanghai', 'Guangzhou', 'Shenzhen')
-
FIELD()对未列出的值返回 0，所以这些行会排在最前；如需排在最后，得加IS NULL或用COALESCE(FIELD(...), 999) - 性能上，
FIELD()在大数据集上比CASE略慢，因为每次都要线性扫描值列表；超过 20 个值时建议改用CASE或临时映射表
用 JOIN 映射表应对复杂或动态顺序
当排序逻辑变多、需要复用，或者顺序本身存在业务表中（比如「品类权重表」），硬编码 CASE 或 FIELD() 就难维护了。这时建一张小映射表，用 JOIN 关联后按权重字段排序，更清晰也更易扩展。
注意别忘了给映射表加索引，尤其是关联字段；另外 LEFT JOIN 要小心，没匹配上的记录权重为 NULL，默认排最前，通常要补 COALESCE(weight, 999) 控制位置。
- 假设有一张
category_order表，含category_name和sort_weight两列 - 查询时：
SELECT t.* FROM products t LEFT JOIN category_order o ON t.category = o.category_name ORDER BY COALESCE(o.sort_weight, 999)
- 这种写法天然支持运行时修改顺序——只需更新映射表，SQL 不用动
PostgreSQL 的 VALUES 构造器 + JOIN
PostgreSQL 支持用 VALUES 构造匿名表，配合 JOIN 实现类似映射表的效果，不用建物理表。适合一次性、轻量级的自定义排序需求。
容易漏的是给 VALUES 结果起别名和字段名，否则 JOIN 时无法引用；另外 VALUES 不支持子查询，顺序值必须是字面量或参数。
- 示例：
SELECT t.* FROM products t JOIN (VALUES ('urgent', 1), ('normal', 2), ('low', 3)) AS v(level, weight) ON t.priority = v.level ORDER BY v.weight - 如果某条记录的
priority不在VALUES列表中，它会被过滤掉（INNER JOIN）；要用 LEFT JOIN 需额外处理NULL权重
实际项目里，CASE WHEN 是最稳的选择；但如果团队只用 MySQL，FIELD() 写起来确实快。真正容易被忽略的是 NULL 值和大小写的处理——它们不会报错，但排序结果会静默错乱。
