结论：case when 错误主因是条件顺序、类型不一致和遗漏 else；顺序错则后续被跳过，类型不统一引发隐式转换或报错，缺 else 导致 null 异常。
直接说结论：用 CASE WHEN 实现条件判断，核心不是“会不会写”，而是“顺序写对没、类型对没、ELSE漏没”。写错这三点，查出来的数据就 quietly 错了——不报错，但结果不对。
WHEN 条件顺序错了，后面全白写
数据库按 WHEN 从上到下逐条判断，一旦命中就返回对应 THEN 结果，**后面的 WHEN 直接跳过**。这点和编程语言里的 if-else 完全一致，但很多人写 SQL 时会忽略。
- 错误写法（永远进不到第二条）：
CASE WHEN amount >= 100 THEN '高价' WHEN amount > 50 THEN '中价' ELSE '低价' END—— amount=80 时只会匹配第一条，返回 '高价' - 正确顺序应是“从严格到宽松”：
CASE WHEN amount >= 100 THEN '高价' WHEN amount > 50 THEN '中价' ELSE '低价' END - 范围判断尤其容易踩坑：比如
BETWEEN或IN写反了区间，或把>和>=混用导致边界遗漏
THEN 和 ELSE 返回值类型不一致会隐式转换或报错
CASE 表达式最终返回一个字段，所有 THEN 和 ELSE 的结果必须能统一成一种数据类型。数据库不会帮你“智能取舍”，而是按规则强制转换——有时转得不对，有时直接报错。
- 常见报错：
[Err] ORA-00932: 数据类型不一致，比如THEN '正常'（字符串）和ELSE 0（数字）混用 - MySQL 可能悄悄把字符串转成数字（
'123'→123），但 PostgreSQL 或 Oracle 会直接拒绝 - 安全做法：显式统一类型，例如都用字符串：
THEN '1'、ELSE '0'；或都转数字：THEN 1、ELSE CAST(NULL AS INTEGER)
在 WHERE 或 GROUP BY 里用 CASE 很容易拖慢查询
CASE WHEN 放在 SELECT 列里一般没问题，但一旦挪到 WHERE 或 GROUP BY，就可能让索引失效、触发全表扫描。
- 反模式：
WHERE CASE WHEN status = 'paid' THEN 1 ELSE 0 END = 1—— 这种写法无法利用status字段上的索引 - 更高效写法：
WHERE status = 'paid'，把逻辑提前到过滤条件本身 - 真需要分类聚合？优先考虑
GROUP BY+CASE在SELECT中，而不是反过来 - 如果业务逻辑复杂到必须在
WHERE用CASE，先 explain 看执行计划，确认没走索引再另谋优化方案（比如加计算列 + 索引）
简单 CASE 和搜索 CASE 别混用场景
两种语法本质不同，适用场景明确：
-
CASE status WHEN 'paid' THEN '已支付'是简单 CASE，只适合**单字段等值匹配**，不能写AND、>、IS NULL等 -
CASE WHEN status = 'paid' AND created_at > '2025-01-01' THEN '新支付'是搜索 CASE，支持任意布尔表达式，日常 90% 场景该用它 - 别为了省几个字符硬套简单 CASE——比如想判断
score BETWEEN 90 AND 100，非要用CASE score WHEN 90 THEN ...，结果只能写几十个WHEN，维护起来就是灾难
最容易被忽略的其实是 ELSE：不写它，没匹配上的行就变成 NULL，而 NULL 在聚合、导出、前端渲染时常常引发意料之外的问题。哪怕只是写 ELSE '未知'，也比留空强。
