SQL中CASE用于ORDER BY的基本写法是通过为不同值分配整数权重实现自定义排序，必须保证所有THEN返回相同数据类型、写ELSE兜底，并避免字符串误作数值排序。
SQL CASE 用于 ORDER BY 的基本写法
直接在 ORDER BY 里用 CASE 表达式，就能绕过字段原始值的自然顺序，实现按业务逻辑排。关键不是“怎么写语法”，而是“怎么组织条件分支”——每个 WHEN 对应一个排序权重，ELSE 必须兜底，否则 NULL 值会排最前（MySQL）或最后（PostgreSQL），行为不一致。
常见错误：漏写 ELSE，或者把字符串直接当排序值（比如 WHEN 'high' THEN '1'），结果按字符串字典序排，不是数值大小。
-
WHEN后面是判断条件，THEN后面必须是可比较的标量（推荐用整数） - 所有
THEN返回类型要一致，避免隐式转换导致排序错乱 - 如果排序字段本身含 NULL，需单独处理：
WHEN status IS NULL THEN 999
按非连续状态值排序（如 status = 'draft', 'review', 'published'）
这种场景不能靠 ORDER BY status，因为字母序是 draft → published → review，明显不合业务。用 CASE 给每个状态硬编码优先级：
ORDER BY
CASE status
WHEN 'draft' THEN 1
WHEN 'review' THEN 2
WHEN 'published' THEN 3
ELSE 4
END
注意：MySQL 和 PostgreSQL 都支持这种写法，但 SQLite 要求 CASE 在 SELECT 列表中定义别名后才能在 ORDER BY 引用（除非用子查询）。
- 状态值写死在 SQL 里，后期增删状态时必须同步改 SQL，不适合高频变更的业务
- 如果状态存在多语言或配置化管理，建议把排序权重抽到维表里做 JOIN，而非硬编码
- 别用字符串拼接生成
CASE（比如 PHP 拼 SQL），容易注入，也难维护
结合多个字段做复合权重排序
单一字段不够，比如“优先显示付费用户，同为付费则按登录时间倒序，免费用户排后面”。这时 CASE 只负责第一层分组，第二层用常规字段补充：
ORDER BY CASE WHEN is_premium = 1 THEN 0 ELSE 1 END, CASE WHEN is_premium = 1 THEN last_login_time END DESC, id DESC
这里用了两个技巧：第一层用 0/1 控制大分组；第二层只对付费用户生效（CASE 返回 NULL 的行，在 DESC 下自动排在最后），避免免费用户也被按登录时间搅乱顺序。
- 不要在一个
CASE里塞太多逻辑，超过 4–5 个WHEN就该考虑拆成函数或预计算列 -
NULL在排序中的位置依赖数据库和NULLS FIRST/LAST设置（PostgreSQL 支持，MySQL 不支持），跨库迁移时要验证 - 如果排序字段上有索引，加了
CASE后几乎一定无法走索引，大数据量时性能会掉得明显
MySQL 8.0+ 与 PostgreSQL 中的差异点
MySQL 5.7 不允许在 ORDER BY 里直接用带聚合或子查询的 CASE，而 MySQL 8.0+ 和 PostgreSQL 都支持更复杂的表达式。但有个坑：PostgreSQL 要求 CASE 所有分支返回类型严格一致，MySQL 会尝试隐式转换（比如 THEN 1 和 THEN '2' 都转成字符串），结果可能和预期不符。
- PostgreSQL 报错
ERROR: CASE types integer and text cannot be matched就是因为类型不统一 - MySQL 里
THEN NOW()和THEN 1混用，结果全变成字符串，排序失效 - SQL Server 要求
CASE必须出现在SELECT列表中才能被ORDER BY引用（除非用子查询）
真实项目里，最常被忽略的是类型一致性 —— 看似只是加个 CASE，实际执行计划可能完全不同，上线前务必在目标环境跑 EXPLAIN 看是否走索引、是否触发文件排序。
