唯一靠谱做法是case when直接写在update的set子句中，必须显式写else column_name防null，多字段需各自独立case，where应先过滤以提升性能，且所有分支返回类型须一致。
直接在 UPDATE 的 SET 子句里写 CASE WHEN，是唯一稳定、跨库兼容、且不依赖额外权限的批量更新方式。其他写法（比如塞进 WHERE、用子查询当值、或试图共用一个 CASE 更新多个字段）要么语法报错，要么静默清空数据。
UPDATE SET 里的 CASE WHEN 怎么写才不丢数据
漏掉 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 - 如果字段定义为
NOT NULL且没默认值，漏ELSE会直接报错：Column 'status' cannot be null - 别依赖数据库隐式行为：MySQL 可能转类型，PostgreSQL 会严格报错，统一用
ELSE column_name最安全
多字段更新时 CASE 必须各自独立
一个 UPDATE 可以同时更新多个字段，但每个字段的逻辑必须单独套一层 CASE WHEN。试图用一个 CASE 控制多个字段赋值，语法不成立。
- ✅ 正确：
SET priority = CASE ... END, discount_rate = CASE ... END - ❌ 错误：
SET (priority, discount_rate) = CASE WHEN ... THEN ('high', 0.1) END（SQL 不支持元组赋值） - PostgreSQL 会拒绝重复字段名：
SET x = CASE ..., x = x + 1报错；MySQL 虽允许，但后一条覆盖前一条，容易误判 - 每个
CASE的所有分支返回类型必须一致，比如不能混用'active'和1，否则 PostgreSQL 直接报错，MySQL 可能隐式转但截断
WHERE 条件必须先过滤，别把业务逻辑全塞进 CASE
把大范围筛选（比如只更新 status = 'pending' 的行）放到 WHERE，而不是靠 CASE 里的条件兜底。否则数据库得扫描全表，索引基本失效。
- 慢：
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'（可用索引） -
WHERE id IN (101, 102, 105)这种写法要确保id字段有索引，否则 10 万行更新可能卡住几秒 - 模糊匹配（如
name LIKE '%admin%'）或函数包裹字段（如DATE(created_at)）会让WHERE失效，务必确认字段已建合适索引
执行前必须验证影响范围和逻辑
生产环境更新前，最危险的不是语法错，而是 WHERE 漏写或写错，导致整张表被重置。
- 先写
SELECT验证：SELECT id, status, CASE WHEN ... END AS new_status FROM users WHERE ... - 再用
SELECT COUNT(*)确认影响行数，和预期是否一致 - 千万别跳过
WHERE测试：哪怕只是WHERE 1=0，也能校验语法是否通过 - 大批量（如超 5000 行）建议分批提交，防止
undo log暴涨或锁表太久
真正容易被忽略的是类型一致性与空值判断逻辑——name = NULL 永远不成立，必须写 name IS NULL；PostgreSQL 要求所有分支返回完全相同类型，MySQL 的隐式转换反而更容易埋雷。
