CASE WHEN是SQL中唯一能安全实现复杂分支的原生手段，仅返回值不控制流程；误用于WHERE会导致索引失效，漏写ELSE在UPDATE中会使字段变NULL，嵌套过深或类型不一致易引发错误。
CASE WHEN 不是“能用”，而是唯一能安全落地复杂分支的 SQL 原生手段；它不控制流程，只返回值，用错位置或漏写关键项，轻则结果错乱，重则整列变 NULL。
WHERE 里硬塞 CASE WHEN 就是自找麻烦
数据库优化器很难对 CASE WHEN 包裹的布尔表达式生成有效索引计划，尤其当它出现在 WHERE 中时，基本等于放弃索引。真实错误写法：WHERE CASE WHEN status = 'pending' THEN created_at > '2026-01-01' ELSE 0 END = 1——这既难读，又让 status 和 created_at 上的索引全失效。
- 正确做法：把确定性筛选条件提前到
WHERE，比如WHERE status = 'pending' AND created_at > '2026-01-01' - 如果真要动态切换条件（如按参数选字段），改用
OR拆解：WHERE (@mode = 'daily' AND log_time >= CURDATE()) OR (@mode = 'hourly' AND log_time >= DATE_SUB(NOW(), INTERVAL 1 HOUR)) - MySQL 8.0+ 支持函数索引，但
CASE表达式本身不能被索引，别指望靠它提速
UPDATE 的 SET 子句里漏写 ELSE 就等于删数据
这是线上事故最高发点：SET status = CASE WHEN paid_at IS NOT NULL THEN 'paid' END 看似没问题，但所有未支付的订单，status 全变成 NULL——因为没匹配的行默认返回 NULL，且不会保留原值。
- 必须显式写
ELSE status，即：SET status = CASE WHEN paid_at IS NOT NULL THEN 'paid' ELSE status END - 若字段定义为
NOT NULL且无默认值，漏ELSE会直接报错：Column 'status' cannot be null - 多个字段更新要各自独立写
CASE，不能共用一个表达式，SET (a, b) = CASE ... END是非法语法
GROUP BY 或 ORDER BY 引用 CASE 必须重复完整表达式
别以为给 CASE 起了别名就能在 GROUP BY 里直接用。PostgreSQL 和 SQL Server 会直接报错：column "grade" does not exist；MySQL 虽可能通过，但行为不可靠。
- 错误：
SELECT name, CASE WHEN score >= 90 THEN 'A' ELSE 'B' END AS grade FROM t GROUP BY grade - 正确：要么重复整个表达式：
GROUP BY CASE WHEN score >= 90 THEN 'A' ELSE 'B' END - 要么用子查询/CTE 提前计算：
SELECT grade FROM (SELECT ..., CASE ... END AS grade FROM t) s GROUP BY grade - ORDER BY 同理，别简写成
ORDER BY grade，除非你确认数据库版本明确支持别名引用
嵌套和聚合里用 CASE 是刚需，但类型必须一致
在 SUM(CASE WHEN region = '华东' THEN amount ELSE 0 END) 这类聚合中，ELSE 0 很关键：如果写成 ELSE NULL，SUM 会忽略它，结果正确；但如果写成 ELSE 'N/A'，PostgreSQL 直接报错，MySQL 可能隐式转成字符串导致求和失败。
- 所有
THEN和ELSE返回值类型必须相同，优先用显式类型：ELSE 0.0（对应浮点金额）、ELSE ''（对应字符串标签） - 嵌套层级别超过 3 层，建议先用子查询算出中间状态码，再单层
CASE映射，比如：SELECT ..., CASE WHEN risk_code = 1 THEN '高危' WHEN risk_code = 2 THEN '观察' ELSE '正常' END - 子查询中用
CASE打标后外层过滤，比在WHERE里堆逻辑更易读、更可控
最常被跳过的细节是：所有分支返回值类型的隐式兼容性，在 PostgreSQL 里是硬性要求，在 MySQL 里却可能悄悄转成字符串再截断——同一段 SQL 换个数据库就出错，问题往往卡在 ELSE 分支的类型没对齐。
