CASE WHEN 可在 UPDATE 的 SET 子句中按条件为同一列赋不同值，需写在 SET 内、显式指定 ELSE 保留原值，注意条件顺序、类型一致、WHERE 先过滤再计算，并避免隐式转换与非确定性函数。
UPDATE 里怎么用 CASE WHEN 更新不同值
直接在 UPDATE 语句中嵌套 CASE WHEN，就能按条件给同一列赋不同值。它不是额外查一遍再更新，而是一次扫描、一次写入，效率比多次 UPDATE 高得多。
常见错误是把 CASE 写在 SET 外面，或者漏掉 ELSE 导致字段被设为 NULL（尤其当没匹配到任何条件时）。
-
SET column_name = CASE WHEN condition1 THEN value1 WHEN condition2 THEN value2 ELSE column_name END——ELSE必须显式回填原值，否则未命中条件的行会变NULL - 条件顺序很重要：
CASE从上到下匹配，第一个为真就执行，后面的不看了 - 所有分支返回的数据类型要一致，比如不能有的分支是字符串、有的分支是数字，否则 MySQL 报
Invalid result type，PostgreSQL 报column "x" is of type text but expression is of type integer
MySQL 和 PostgreSQL 的 CASE WHEN 写法差异
核心逻辑一样，但细节有坑。比如 MySQL 允许在 CASE 中直接比较 NULL（WHEN column IS NULL），而 PostgreSQL 要写成 WHEN column IS NULL，不能写 = NULL —— 后者永远返回 FALSE。
另一个关键点：PostgreSQL 对 ELSE 分支类型更严格，如果主列是 TEXT，你却在某个 THEN 里写了 123，它不会自动转字符串，直接报错。
- MySQL 支持简写形式：
CASE column WHEN 'a' THEN 1 WHEN 'b' THEN 2 END；PostgreSQL 也支持，但仅限等值判断，不能用>或IN - 跨数据库移植时，优先用完整形式：
CASE WHEN column > 100 THEN 'high' ELSE 'low' END - 别在
CASE里调用非确定性函数（如NOW()、RAND()），MySQL 可能每行都重新算，PostgreSQL 则通常只算一次——行为不一致，容易出 bug
WHERE + CASE WHEN 混用时的性能陷阱
有人想“只更新满足某些条件的行”，于是把业务逻辑全塞进 CASE，结果发现慢得离谱。其实应该先用 WHERE 过滤大范围，再用 CASE 做精细赋值。
比如更新用户等级：只有 status = 'active' 的才参与计算。如果省略 WHERE status = 'active'，数据库就得扫描全表，哪怕 90% 的行根本不会被改。
-
UPDATE users SET level = CASE WHEN score >= 90 THEN 'A' WHEN score >= 80 THEN 'B' ELSE 'C' END WHERE status = 'active'—— 先过滤再计算，索引能用上 - 避免在
CASE条件里用函数包裹字段，比如WHEN YEAR(created_at) = 2023，这会让created_at上的索引失效 - 如果条件特别复杂（比如涉及子查询或关联表），考虑拆成临时表或 CTE，别硬塞进单条
UPDATE
更新失败却没报错？检查隐式类型转换和 NULL
最常被忽略的是字段定义和 CASE 返回值之间的类型隐式转换。比如目标列是 VARCHAR(10)，你在某个 THEN 分支里拼了个超长字符串，MySQL 可能截断、PostgreSQL 直接报错，但有些客户端不显示警告，看起来像“没更新成功”。
还有就是忘记 ELSE，导致部分行被设成 NULL，而你又没开 NOT NULL 约束，数据就静默损坏了。
- 执行前加
SELECT验证逻辑：SELECT id, name, CASE WHEN ... END AS new_level FROM users WHERE ...，确认结果符合预期 - 对关键字段开启
NOT NULL约束，并设置默认值，能拦住大部分因ELSE缺失导致的空值 - MySQL 5.7+ 默认开启
STRICT_TRANS_TABLES，但老版本或某些配置下仍可能静默截断，务必查SHOW VARIABLES LIKE 'sql_mode'
