case when执行顺序是从上到下、命中即止，一旦某when条件为真即返回对应then值并跳过后续判断，与if-else if-else逻辑一致，且所有主流数据库均严格遵循该顺序不重排。
CASE WHEN 的执行顺序是“从上到下、命中即止”
它不是并行判断所有条件，而是逐条检查 WHEN 子句——一旦某个条件为 TRUE，就立刻返回对应 THEN 的值，后续 WHEN 全部跳过。这点和编程语言里的 if-else if-else 完全一致。
常见错误现象：把范围大的条件写在前面，导致小范围分支永远不生效。比如：
SELECT
CASE
WHEN amount > 0 THEN '正数'
WHEN amount > 100 THEN '超百'
ELSE '非正数'
END AS label
这里 amount > 100 永远不会被触发，因为所有大于 100 的数都先满足了 amount > 0。
- 写范围条件时，务必从细到粗（如先
，再 <code>，最后 <code>ELSE） - 用
BETWEEN或IN替代多个等值判断时，顺序无关，但混合使用时仍受执行顺序影响 - PostgreSQL 和 MySQL 都严格遵循该顺序，不存在“优化重排”行为
WHERE 中用 CASE WHEN 必须返回标量，不能直接当布尔表达式
CASE WHEN 在 WHERE 子句里不是用来替代 AND/OR 的开关，它本质是值生成器。数据库执行顺序是 WHERE → GROUP BY → HAVING → SELECT，所以 CASE 必须产出一个可比较的值，再配合运算符使用。
错误写法（MySQL 报错，PostgreSQL 可能静默转义）：
WHERE CASE WHEN status = 1 THEN TRUE ELSE FALSE END
正确写法（显式比较）：
WHERE CASE WHEN status = 1 THEN 1 ELSE 0 END = 1
- 优先考虑改写为原生布尔逻辑：
WHERE (status = 1 AND ...)，更易索引、更可读 - 如果分支多且逻辑耦合紧（如按地区+时间动态计算阈值），才用
CASE+ 比较，但要注意类型对齐（别混用字符串和数字） - MySQL 5.7+ 允许
CASE ... END IS TRUE，但 PostgreSQL 不支持，跨库场景必须回避
SELECT 中的类型对齐问题常被忽略
CASE WHEN 所有 THEN 和 ELSE 分支返回的值，会被数据库统一推导为一个公共类型。这个过程不是“选最长字符串”，而是按类型优先级隐式转换——MySQL 可能把整数转成 VARCHAR(1) 导致截断，PostgreSQL 则直接报错。
示例（危险）：
SELECT CASE WHEN flag = 1 THEN 100 ELSE 'N/A' END FROM t
在 PostgreSQL 中会报错：ERROR: CASE types integer and text cannot be matched；MySQL 可能转成字符串但长度失控。
- 显式类型转换最稳妥：
CAST(100 AS TEXT)或CONCAT('', 100) - 没写
ELSE时，默认返回NULL，类型由第一个THEN决定——这点容易让前端空值处理出错 - 聚合场景下混用
CASE和SUM，更要确认所有分支是否都允许参与数值计算（比如'N/A'会让整个SUM变成NULL）
ORDER BY 里滥用 CASE WHEN 会失效索引
把 CASE WHEN 直接塞进 ORDER BY，看起来能实现“VIP 用户排前面”，但数据库无法利用原始列上的索引，每次都要全表计算排序键。
例如：
ORDER BY CASE WHEN level = 'vip' THEN 0 ELSE 1 END, created_at DESC
即使 level 和 created_at 都有索引，这条语句也大概率走全表扫描。
- 高频排序需求，建议新增生成列（MySQL 5.7+）或物化列（PostgreSQL），并为其建索引
- 临时性排序，可用
UNION ALL拆成两个有序子查询再合并，性能通常更好 - 注意
NULL在排序中的位置：不同数据库默认NULLS FIRST或NULLS LAST，CASE未覆盖的分支返回NULL会导致顺序不可控
