CASE WHEN在UPDATE的SET子句中直接使用是唯一靠谱做法，必须写ELSE保留原值，多字段需各自独立CASE，WHERE应先过滤以提升性能，且所有分支返回类型须一致。
CASE WHEN 在 UPDATE 的 SET 子句里直接用，是唯一靠谱做法。它不是“能用”，而是标准、高效、跨库兼容的批量更新手段；所有主流数据库（MySQL 8.0+、PostgreSQL、SQL Server、Oracle）都支持，且一条语句完成多条件赋值，避免应用层循环或多次 UPDATE。
UPDATE 的 SET 里必须写 ELSE，否则字段变 NULL
漏掉 ELSE 是最隐蔽的数据事故源头：不匹配任何 WHEN 条件的行，该字段会被设为 NULL——即使原值非空，也不保留。这不是语法错误，但线上数据可能悄无声息被清空。
-
SET status = CASE WHEN paid_at IS NOT NULL THEN 'paid' END→ 所有未支付的订单，status全变NULL - 正确写法：
SET status = CASE WHEN paid_at IS NOT NULL THEN 'paid' ELSE status END，ELSE status显式回填原值 - 若字段定义为
NOT NULL且没设默认值，漏ELSE会直接报错：Column 'status' cannot be null
多个字段要各自独立写 CASE，不能共用一个
一个 UPDATE 语句可以同时更新多个字段，但每个字段的逻辑必须独立封装在自己的 CASE WHEN 中。试图用一个 CASE 控制多个字段赋值，语法不成立，也违背可读性原则。
- ✅ 正确：
SET status = CASE ... END, updated_at = CASE ... END - ❌ 错误：
SET (status, updated_at) = CASE WHEN ... THEN ('paid', NOW()) ... END（SQL 不支持元组式赋值） - 注意 PostgreSQL 会拒绝重复字段名：
SET x = CASE ..., x = x + 1报错；MySQL 允许但后一条覆盖前一条，容易误判
WHERE 必须先过滤，别把业务逻辑全塞进 CASE
把大范围筛选（比如只更新 status = 'pending' 的行）放到 WHERE，而不是靠 CASE 里的条件兜底。否则数据库得扫描全表，哪怕 95% 的行根本不会被改，索引也基本失效。
- 慢：
UPDATE orders SET status = CASE WHEN status = 'pending' AND paid_at IS NOT NULL THEN 'paid' ... END（全表扫描） - 快：
UPDATE orders SET status = CASE WHEN paid_at IS NOT NULL THEN 'paid' ... END WHERE status = 'pending'（索引可用） - 模糊匹配（如
LIKE '%admin%'）或函数包裹字段（如DATE(created_at)）会进一步拖慢速度，务必确认字段已建合适索引
真正容易被忽略的是类型一致性：PostgreSQL 要求所有 THEN 和 ELSE 返回完全相同类型，CASE WHEN flag = 1 THEN 'yes' ELSE 0 END 直接报错；MySQL 会隐式转成字符串，但可能导致数值截断或警告。上线前最好在测试库用真实数据跑一遍 SELECT 验证返回类型。
