MySQL的UPDATE语句不支持IF...THEN...END IF控制流，仅允许IF()函数或CASE WHEN表达式在SET子句中实现字段级条件赋值，WHERE仅用于行过滤。
UPDATE 里直接写 IF 判断会报错
MySQL 的 UPDATE 语句本身不支持 IF 关键字作为条件分支（像存储过程里那样），直接写 IF(condition, a, b) 是合法的，但写 IF ... THEN ... END IF 会语法错误。很多人卡在这儿，以为 UPDATE 能嵌套完整控制流。
真正能用的是表达式级别的条件函数：IF()（MySQL）、CASE WHEN（标准 SQL，兼容性更好）。它们返回值，不是执行分支逻辑。
-
IF(condition, value_if_true, value_if_false)：仅 MySQL 支持，三元表达式风格 -
CASE WHEN condition THEN value ELSE value END：所有主流数据库都支持，推荐优先用 - 别在
WHERE子句里塞IF()做过滤——它没意义，WHERE本来就是布尔判断
覆盖逻辑写在 SET 子句，不是 WHERE
“有条件覆盖”本质是：同一行数据，某些字段按条件更新为 A，另一些按条件更新为 B，而不是“满足条件才更新整行”。后者用 WHERE 就够了；前者必须把条件逻辑放到 SET 里。
比如：订单状态为 'pending' 时，把 processed_at 设为 NOW()，否则保持原值；同时，只要金额 > 100，就把 priority 设为 'high'。
UPDATE orders SET processed_at = CASE WHEN status = 'pending' THEN NOW() ELSE processed_at END, priority = CASE WHEN amount > 100 THEN 'high' ELSE priority END WHERE id = 123;
- 每个字段的赋值独立判断，互不影响
-
ELSE分支写原字段名，才能实现“不变”效果；写NULL或省略会导致清空 - 如果漏写
WHERE，整表都会被扫描+更新——哪怕CASE最终没改任何值，也触发日志和锁
UPDATE + JOIN 实现跨表条件覆盖
当覆盖逻辑依赖另一张表的数据（比如用用户等级决定折扣），不能只靠子查询，得用 JOIN 把关联数据拉进来再判断。
常见错误：在 SET 里写相关子查询，性能爆炸且可能出错；或者用两个独立 UPDATE，产生竞态。
UPDATE orders o JOIN users u ON o.user_id = u.id SET o.discount = CASE WHEN u.level = 'vip' THEN 0.2 WHEN u.level = 'gold' THEN 0.1 ELSE o.discount END WHERE o.status = 'confirmed';
- 必须明确
JOIN类型——这里用INNER JOIN，确保用户存在；若允许匿名订单，得考虑LEFT JOIN+IS NULL处理 -
WHERE过滤仍要保留，避免无谓更新；JOIN 条件和业务条件分开写更清晰 - MySQL 8.0+ 支持
UPDATE ... FROM语法，但可读性不如显式 JOIN，且 PostgreSQL/SQL Server 写法不同，跨库迁移成本高
NULL 和默认值容易被 CASE 忽略
CASE 表达式不会自动处理 NULL——如果判断字段本身是 NULL，WHEN field = 'x' 永远不匹配，最后落到 ELSE。这常导致“本该覆盖却没动”的静默问题。
例如：想把 category 为空或 'unknown' 的记录统一设为 'other'，只写 WHEN category = 'unknown' 不够。
- 显式检查
IS NULL：WHEN category IS NULL OR category = 'unknown' - 或用
COALESCE(category, '')统一转空字符串再比 - 注意字段默认值（如
NOT NULL DEFAULT 'default'）会影响判断逻辑，别假设“没填就是 NULL” - 测试时务必构造
NULL、空字符串、空白字符串（' '）三类数据，它们行为完全不同
条件覆盖不是写完就完，关键在边界值是否被 CASE 的每个分支真正捕获。漏掉一个 NULL 分支，线上就可能积压一批没更新的脏数据。
