update中嵌套case when的基本写法是将每个case when置于set子句中对应列的赋值右侧，每列独立书写，必须包含else分支回填原值以防null，且where需显式过滤以提升性能和安全性。
UPDATE 中嵌套 CASE WHEN 的基本写法
SQL 的 UPDATE 语句本身不支持对同一行的多个列分别用独立条件赋值，但可以通过在 SET 子句里为每一列单独写一个 CASE WHEN 表达式来实现——不是“一个 CASE 控制多列”，而是“每列一个 CASE”。这是最常用也最稳妥的做法。
常见错误是试图写成这样（语法报错）：
UPDATE users
SET (status, level) = CASE WHEN id = 1 THEN ('active', 5) ELSE ('inactive', 1) END;
实际必须拆开：
UPDATE users SET status = CASE WHEN id = 1 THEN 'active' ELSE 'inactive' END, level = CASE WHEN id = 1 THEN 5 ELSE 1 END WHERE id IN (1, 2, 3);
-
CASE WHEN必须出现在每个列的赋值右侧，不能共用一个表达式 -
WHERE条件建议显式加上，避免全表扫描或误更新 - 所有分支的返回类型要一致，比如
CASE返回字符串时，ELSE不能返回NULL而没声明类型（某些数据库如 PostgreSQL 对类型推导更严格）
多条件组合更新：WHEN 子句顺序很重要
当一列需要按多个条件设置不同值时，CASE WHEN 的分支顺序直接影响结果——它从上到下匹配，遇到第一个为 TRUE 的 WHEN 就停止。顺序写反会导致逻辑覆盖。
例如想把订单按金额分级，但把 amount 和 <code>amount 的顺序颠倒：
UPDATE orders SET priority = CASE WHEN amount
- 条件范围宽的放后面，窄的放前面（比如先判
，再判 <code>） - 可以加注释说明区间含义，尤其当条件含
BETWEEN或IS NULL时 - 测试时用
SELECT先验证CASE表达式逻辑，比如：SELECT id, amount, CASE ... END AS new_priority FROM orders LIMIT 10
NULL 值与缺失 ELSE 分支的风险
漏写 ELSE 不会报错，但会让未匹配条件的行该列被设为 NULL——这在生产环境极易引发数据丢失，且难以回溯。
比如更新用户状态时只写了活跃用户的分支：
UPDATE users SET status = CASE WHEN last_login > '2024-01-01' THEN 'online' END WHERE id > 1000;
结果是所有 last_login 的用户 <code>status 全变 NULL。
- 只要
CASE出现在SET中，就默认有隐式ELSE NULL - 明确写出
ELSE，哪怕只是保留原值：ELSE status（注意不是ELSE NULL） - 涉及可空列时，检查目标列是否允许
NULL；不允许的话，缺ELSE会直接报错（如 MySQL 严格模式）
性能和兼容性注意事项
在大表上用多层 CASE WHEN 更新，本质上仍是全字段计算 + 行级更新，无法跳过无关行。如果条件能提前过滤，优先靠 WHERE 减少扫描量。
- MySQL 8.0+、PostgreSQL、SQL Server 都完全支持这种写法；SQLite 支持但不支持
THEN后跟子查询 - Oracle 中注意：如果
CASE内部引用了其他表字段（比如关联更新），需改用MERGE或子查询，原写法不适用 - 单条
UPDATE里列数过多 +CASE层级过深，可能触发某些数据库的表达式长度限制（如 SQL Server 的 10 层嵌套上限） - 真正大批量差异化更新（比如十万行每行值都不同），考虑用临时表
JOIN更新，比堆砌CASE更清晰、易维护、易审计
最常被忽略的一点：CASE 表达式里的字段别名不能复用，比如不能在第二个列的 CASE 中引用第一个列刚算出的别名——所有 CASE 都基于原始行值计算，没有中间状态。
