update中嵌套case when的正确写法是将其置于set子句中作为赋值表达式，必须带else回填原值以防null，多字段需各自独立case，where应先精确过滤以提升性能，且所有分支返回类型须一致。
UPDATE 中嵌套 CASE WHEN 的基本写法
直接在 SET 子句里用 CASE WHEN，不是在 WHERE 里——这是最常混淆的点。数据库执行顺序是先计算 CASE 表达式结果，再赋值给字段，整个语句仍是一次性更新。
- 每个
WHEN分支必须返回相同数据类型，否则 MySQL 报Operand should contain 1 column(s)，PostgreSQL 报column "x" is of type text but expression is of type integer -
ELSE不是可选的：不写且无匹配分支时，该行该字段会被设为NULL（即使原值非空） - 示例（MySQL/PostgreSQL 通用）：
UPDATE orders SET status = CASE WHEN total > 1000 THEN 'premium' WHEN total BETWEEN 100 AND 1000 THEN 'standard' ELSE 'trial' END WHERE created_at > '2024-01-01';
多字段、多条件组合更新时的写法陷阱
别为每个字段单独写一个 CASE 块再拼到一起——语法合法但逻辑易错；更稳妥的是让每个 CASE 独立控制一个字段，用同一组条件判断。
- 条件重复写没关系，但别试图用“变量”缓存中间判断结果（SQL 标准不支持变量绑定到
CASE条件中） - 如果条件涉及关联表，必须用
JOIN或子查询提前把维度拉进来，不能在CASE里写(SELECT ...)——某些数据库（如 SQLite）会报错或性能极差 - 示例（同时更新两个字段）：
UPDATE users u JOIN user_profiles p ON u.id = p.user_id SET u.level = CASE WHEN p.score >= 90 THEN 'A' WHEN p.score >= 70 THEN 'B' ELSE 'C' END, u.is_vip = CASE WHEN p.membership_type IN ('gold', 'platinum') THEN 1 ELSE 0 END WHERE u.status = 'active';
避免 WHERE 和 CASE 逻辑重叠导致意外覆盖
很多人习惯先加 WHERE 缩小范围，再在 CASE 里做细分——这没问题；但若 WHERE 条件太宽，而 CASE 又没兜底，就容易把不该动的行设成 NULL。
- 典型错误：写
WHERE status != 'archived'，但CASE只覆盖了'pending'和'shipped'，漏掉'cancelled'→ 这些行的status被置为NULL - 解决办法只有两个：要么在
CASE末尾加ELSE u.status（保持原值），要么把WHERE写精确，例如WHERE status IN ('pending', 'shipped', 'cancelled') - 注意：用
ELSE u.status会阻止索引下推优化，在大表上可能变慢
PostgreSQL / SQL Server 对 NULL 和布尔条件的特殊处理
MySQL 把 NULL = NULL 当 false，而 PostgreSQL 和 SQL Server 遵循三值逻辑：NULL = NULL 是 UNKNOWN，不会进 WHEN 分支。
- 在 PostgreSQL 中，判断字段是否为
NULL必须写WHEN col_name IS NULL，不能写WHEN col_name = NULL - SQL Server 支持
IIF()，但嵌套过深时不如CASE可读；且IIF(NULL, 1, 0)返回0，而CASE WHEN NULL THEN 1 ELSE 0 END也返回0——表面一致，底层行为不同，跨数据库迁移时容易出错 - 如果条件含布尔字段（如
is_active），PostgreSQL 允许直接写WHEN is_active，SQL Server 要写WHEN is_active = 1，MySQL 则两者都接受
实际执行前，建议先用 SELECT 模拟 CASE 逻辑：
SELECT id, status,
CASE
WHEN total > 1000 THEN 'premium'
ELSE status
END AS new_status
FROM orders
WHERE created_at > '2024-01-01'
LIMIT 5;
CASE WHEN 更新本身不难，难的是条件分支之间隐含的排他性、NULL 处理的一致性，以及不同数据库对空值和布尔值的解释差异——这些地方不动手试一次，光看文档很容易漏。
