MySQL中用CASE WHEN按条件更新字段，必须将CASE置于SET右侧作为赋值表达式，每个字段需独立CASE，务必写ELSE回退原值以防NULL，且WHERE不可省并需索引支持。
MySQL 中用 CASE WHEN 实现按条件更新字段
直接在 UPDATE 语句里嵌套 CASE WHEN 是最稳妥、兼容性最好的方式，尤其适合只更新部分列、其他字段保持原值的场景。它不依赖存储过程，也不要求字段有默认值。
常见错误是把 CASE 写在 SET 外面，或漏掉 ELSE——没写 ELSE 时条件不匹配会导致该字段被设为 NULL，这往往不是你想要的。
- 必须对每个需条件更新的字段单独写一个
CASE表达式 -
ELSE推荐显式写成原字段名（如ELSE status），避免意外置空 - 多个字段更新时，
CASE之间用英文逗号分隔，不要加AND
UPDATE orders
SET status = CASE
WHEN paid_at IS NOT NULL THEN 'paid'
WHEN created_at < DATE_SUB(NOW(), INTERVAL 7 DAY) THEN 'expired'
ELSE status
END,
updated_at = NOW()
WHERE id IN (101, 102, 105);
PostgreSQL 或 SQL Server 中不能用 IF 函数做更新逻辑
SQL 标准里没有全局可用的 IF() 函数；MySQL 有 IF(expr, true_val, false_val)，但 PostgreSQL 和 SQL Server 只支持 CASE。硬套 MySQL 的 IF 到其他数据库会报错：ERROR: function if(unknown, unknown, unknown) does not exist。
即使在 MySQL 里，IF 也仅限单层二选一，嵌套三层以上可读性迅速下降，而 CASE 支持任意分支且结构清晰。
- PostgreSQL 必须用
CASE，不支持IF作为标量函数 - SQL Server 的
IIF()是 2012+ 版本才引入，且不支持在UPDATE ... SET中直接用于字段赋值逻辑（会报错Incorrect syntax near 'IIF'） - 跨数据库迁移时，统一用
CASE能省去大量语法适配工作
WHERE 条件和 CASE 逻辑别混在一起
有人试图用 WHERE 过滤出“需要更新的行”，再统一赋值，但这无法处理同一张表里不同行需更新不同字段的场景。比如：订单 A 要改 status，订单 B 要改 shipping_method，两者逻辑互斥——这时只能靠 CASE 在同一语句中分流。
另一个典型坑是把业务判断全塞进 WHERE，导致更新范围过大或遗漏。例如：WHERE status = 'pending' AND amount > 100 看似合理，但如果后续还要给 amount 的 pending 订单打标记，就得再跑一条语句，增加并发冲突风险。
-
WHERE控制影响哪些行，CASE控制每行更新哪些值——职责必须分开 - 如果某字段只在极少数情况下才变更，
CASE中对应分支可直接写ELSE column_name，避免无谓写操作 - 高频更新场景下，尽量让
CASE分支覆盖所有可能取值，减少执行计划波动
注意 NULL 值参与判断时的陷阱
CASE WHEN col = NULL 永远不成立，因为 NULL = NULL 返回 UNKNOWN，不是 TRUE。实际写的时候得用 IS NULL 或 IS NOT NULL。
更隐蔽的问题是：当 CASE 的某个分支返回 NULL（比如 ELSE NULL），而目标字段是 NOT NULL 且无默认值，整条 UPDATE 就会失败，报错 Column 'xxx' cannot be null。
- 所有涉及
NULL的比较，一律用IS [NOT] NULL - 确保每个
CASE分支都有明确返回值，尤其是ELSE不要留空 - 若字段允许
NULL，但业务上不允许为空，应在CASE中兜底，例如ELSE COALESCE(old_value, 'default')
