CASE WHEN 是批量更新不同行的标准解法，需置于 SET 后、带 ELSE 分支，注意类型一致、空值写法及主键冲突规避。
批量更新不同行用 CASE WHEN 最直接
想让同一 UPDATE 语句给多行设不同值，CASE WHEN 是标准解法。它本质是把“按条件分支赋值”的逻辑塞进赋值表达式里，数据库逐行计算后写入，不依赖循环或多次执行。
常见错误是把 CASE 写在 WHERE 后面，或者漏掉 ELSE 导致部分行被设为 NULL（尤其当没匹配到任何 WHEN 条件时）。
-
UPDATE语句中，SET column = CASE ... END是唯一合法位置；CASE不能独立成子句 - 必须有
ELSE分支，否则未覆盖的行该列会变NULL（除非你明确想要这个行为） - 所有
WHEN分支返回的数据类型要一致，否则可能触发隐式转换或报错（如混用字符串和数字）
CASE WHEN 更新带主键/唯一约束的场景要小心
当更新字段是主键、唯一索引列，或更新后可能违反约束时，数据库会按行顺序检查，不是先算完所有新值再统一校验。这意味着：即使逻辑上“交换两行的 ID”可行，但 CASE 直接写可能因中间状态冲突而失败。
- 例如：把
id=1改成2，同时把id=2改成1，多数数据库会报duplicate key - 绕过方法：先用临时值（如负数、加前缀）占位，再二次更新；或改用
JOIN+ 临时表（见下一条） - MySQL 8.0+ 和 PostgreSQL 支持
UPDATE ... FROM或JOIN语法，更适合复杂映射关系
数据量大时，CASE WHEN 分支别超 50 个
分支过多会让 SQL 可读性骤降，也影响优化器生成执行计划。PostgreSQL 对 CASE 分支数无硬限制但编译慢；SQL Server 在分支超百时可能报 query processor could not produce a query plan；MySQL 虽不报错，但解析耗时明显上升。
- 超过 20–30 个分支，建议拆成临时表 +
JOIN更新：UPDATE t JOIN temp_map m ON t.id = m.old_id SET t.status = m.new_status
- 分支逻辑有规律（如按区间、正则、字符串前缀），优先用函数替代枚举：
CASE WHEN name LIKE 'A%' THEN 'group_a' ... - 应用层拼 SQL 时，注意防止注入——
CASE分支内容必须来自可信源或预定义枚举，不可直插用户输入
MySQL 与 PostgreSQL 的 CASE 行为差异点
两者语法兼容，但执行细节不同。最常踩的坑是空值处理和类型推断：
- MySQL 中
CASE WHEN col = NULL永远不成立，得写col IS NULL；PostgreSQL 同理，但部分旧版本允许非标准写法 - PostgreSQL 要求所有
THEN返回同类型，MySQL 会尝试隐式转（比如THEN 1和THEN 'abc'会导致整列转为字符串） - MySQL 的
UPDATE ... ORDER BY可配合CASE控制更新顺序（用于规避唯一冲突），PostgreSQL 不支持该语法
实际写的时候，先确认目标数据库版本，再决定是否加 ELSE、是否显式 CAST、以及要不要分步走——这些细节不处理，上线后才发现部分数据被清空或类型错乱，排查成本远高于前期多写一行。
