case when 在 update 中必须作为 set 子句中字段的赋值表达式使用，不可独立出现；必须显式写 else 避免设为 null，各分支返回值类型须一致，判空用 is null 而非 = null。
CASE WHEN 在 UPDATE 中怎么写才不会报错
直接在 UPDATE 的 SET 子句里用 CASE WHEN 是最常用也最安全的方式，不能把它塞进 WHERE 或当表名/字段名用。常见错误是写成 UPDATE ... WHERE CASE WHEN ...，这在标准 SQL（包括 MySQL、PostgreSQL、SQL Server）里语法不合法。
正确结构是：
UPDATE table_name SET column_name = CASE WHEN condition1 THEN value1 WHEN condition2 THEN value2 ELSE column_name -- 注意：必须有 ELSE，否则不匹配的行会被设为 NULL END WHERE some_base_condition;
-
ELSE分支不能省——漏掉会导致非匹配行的该字段被更新为NULL -
WHERE子句建议加上基础过滤条件（比如只更新状态为 'pending' 的记录），避免全表扫描和意外覆盖 - 所有
THEN后的值类型要一致，否则可能触发隐式转换或报错（如 PostgreSQL 对类型严格）
一次更新多个字段，CASE WHEN 要不要分开写
每个字段的逻辑独立，就必须各自写一个 CASE WHEN 表达式。不能共用一个 CASE 块去同时决定两个字段的值——SQL 不支持“多分支返回多列”这种写法。
例如想按地区调整价格和折扣：
UPDATE products
SET
price = CASE
WHEN region = 'CN' THEN price * 1.05
WHEN region = 'US' THEN price * 1.10
ELSE price
END,
discount_rate = CASE
WHEN region = 'CN' THEN 0.05
WHEN region = 'US' THEN 0.10
ELSE discount_rate
END
WHERE status = 'active';
- 两个
CASE独立计算，互不影响 - 每个都带
ELSE回退到原值，确保未命中条件的字段不变 - 如果某个字段更新逻辑依赖另一个字段的新值（比如先改
price，再用新price算discount_amount），SQL 不允许在同一条UPDATE里引用刚更新的字段——得拆成两条语句或用子查询
MySQL 和 PostgreSQL 在 CASE WHEN 更新时的关键差异
行为大体一致，但有两个实际踩坑点：
- MySQL 允许在
SET中直接引用即将被更新的字段（如SET x = CASE WHEN y > 0 THEN x + 1 ELSE x END），而 PostgreSQL 要求显式写ELSE x，否则报错“column reference 'x' is ambiguous” - PostgreSQL 对
CASE返回类型推导更严格：如果THEN分支一个是INTEGER、一个是TEXT，会直接报错；MySQL 可能静默转成字符串，导致数值比较失效 - 两者都不支持在
CASE中调用写操作函数（如NEXTVAL()或UUID()）多次——结果可能重复或不可预期，需用子查询或 CTE 预生成
为什么 WHERE 条件里套 CASE WHEN 总是慢
不是语法问题，而是执行计划问题：WHERE CASE WHEN ... 写法本身不合法，但有人误写成 WHERE (CASE WHEN ... THEN 1 ELSE 0 END) = 1。这种写法会让数据库无法使用索引，强制走全表扫描。
真正该做的是把条件逻辑前置到 WHERE，让 CASE 只管赋值：
- ❌ 错误（无索引友好性）：
WHERE (CASE WHEN status = 'A' THEN id ELSE -1 END) IN (101, 102) - ✅ 正确（可走索引）：
WHERE status = 'A' AND id IN (101, 102)，再在SET里用CASE做差异化赋值 - 批量更新量大时，务必确认
WHERE条件能命中索引——CASE WHEN本身不参与索引优化
复杂业务规则若真需要动态判定是否更新某行，优先考虑用临时表或 CTE 预筛选 ID 列表，而不是靠 CASE 在 WHERE 里硬扛。
