case when 应用于 update 的 set 子句实现多分支条件更新，需显式 else 保留原值；关联表更新优先用 inner join；单条件更新应直接用 where；并发场景必须在 where 中校验旧值以保证原子性。
UPDATE 语句里用 CASE WHEN 实现条件更新
直接在 UPDATE 中嵌套 CASE WHEN 是最常用、最可控的方式。它不依赖外部逻辑，所有判断都在 SQL 层完成，避免应用层多次查询+更新带来的竞态和性能损耗。
常见错误是把 CASE 写成多条独立的 UPDATE，结果要么覆盖前一条，要么漏掉分支；或者忘记写 ELSE，导致未匹配行被设为 NULL（尤其对非空字段很危险）。
使用场景包括：按状态分流更新（如订单状态为 'paid' 才更新发货时间）、按数值区间设置等级字段、根据关联表存在性决定是否覆盖值。
-
CASE必须出现在SET子句右侧，每个字段单独包裹，不能整个SET套一个CASE - 推荐显式写
ELSE old_column_name，确保未命中条件时字段值不变 - 条件表达式支持子查询，但需注意性能——避免在
WHEN中写关联子查询并作用于每行
UPDATE orders
SET
status = CASE
WHEN amount > 1000 THEN 'premium'
WHEN amount > 100 THEN 'standard'
ELSE status -- 关键：保留原值
END,
updated_at = NOW()
WHERE id IN (101, 102, 105);
用 JOIN 关联另一张表做条件判断再更新
当更新依据来自另一张表（比如“只有用户在 users_vip 表中存在，才把 is_vip 设为 1”），用 UPDATE ... JOIN 比先查 ID 再更新更安全高效——避免应用层两次网络往返，也规避了中间数据变更导致的不一致。
容易踩的坑是误用 LEFT JOIN 后没加 WHERE 过滤，结果把所有行都更新了（JOIN 成功的设值，失败的因 NULL 判断变成 0 或默认值）；或者 JOIN 条件写错，导致笛卡尔积式更新。
- 优先用
INNER JOIN显式表达“仅更新有匹配的行” - 若必须用
LEFT JOIN，SET中要用IF(t2.id IS NOT NULL, 1, t1.is_vip)之类逻辑保底 - MySQL 不支持在
UPDATE的FROM子句中直接引用目标表别名（会报You can't specify target table for update in FROM clause），必须用 JOIN 替代
UPDATE users AS t1 INNER JOIN users_vip AS t2 ON t1.id = t2.user_id SET t1.is_vip = 1, t1.vip_level = t2.level WHERE t1.status = 'active';
WHERE 子句本身已能过滤，就别硬套 CASE
如果更新逻辑只是“满足 A 条件的行，把 X 字段设为 Y”，那直接用 WHERE 最简洁、索引友好、执行计划清晰。强行塞进 CASE 反而让优化器难以选择索引，还增加解析开销。
典型误用：看到别人用 CASE 就照搬，结果把单条件更新写成 CASE WHEN condition THEN value ELSE column END，既没收益又难读。
- 单条件更新：用
WHERE condition+ 直接赋值 - 多分支互斥更新（且各分支目标值不同）：才上
CASE - 混合场景（如“大部分行更新 timestamp，少数行额外更新 status”）：仍建议拆成两条
UPDATE，比一个带复杂CASE的语句更容易维护和压测
事务与并发更新要注意什么
条件更新常用于状态流转（如“只有当前 status = 'pending' 才允许设为 'processing'”），这类操作天然需要原子性和一致性。裸写 UPDATE 不保证“检查+更新”是原子的，高并发下可能超发或状态错乱。
真正关键的是 WHERE 中包含旧值校验（即“compare-and-swap”语义），而不是靠应用层先 SELECT 再 UPDATE——后者有竞态窗口。
- 务必在
WHERE中同时写条件和待更新字段的当前值，例如WHERE status = 'pending' AND id = 123 - 执行后检查
ROW_COUNT()返回值，如果是 0，说明条件不满足（已被其他事务改过），不是“没找到记录” - 不要依赖
SELECT ... FOR UPDATE加锁来替代 WHERE 校验——锁住的行太多会影响吞吐，且无法防止幻读引发的逻辑错误
复杂业务规则（比如“同一用户 24 小时内只能成功更新一次”）很难纯靠 SQL 表达，这时候该上应用层幂等控制或分布式锁，而不是在 MySQL 里堆 CASE 和子查询。
