最稳妥方式是UPDATE...SET status = CASE WHEN...THEN...ELSE status END；必须写ELSE status防NULL，WHERE需预过滤而非依赖CASE判断，各分支值类型须一致。
MySQL里用CASE更新多状态字段最稳
直接说结论：用 UPDATE ... SET status = CASE WHEN ... THEN ... END 是批量更新状态机字段最干净、最可控的方式。比写多个 UPDATE 语句或应用层循环更安全，也比触发器或存储过程更透明、易调试。
CASE表达式必须写完整ELSE分支
漏掉 ELSE 不会报错，但会让没匹配上的行被设成 NULL —— 这是线上事故高频原因。状态字段通常不允许为 NULL，且业务逻辑往往默认“不匹配就保持原值”。
实操建议：
- 所有
CASE必须显式写ELSE status（假设字段名是status） - 如果字段有
NOT NULL约束，不写ELSE会导致语句直接失败（MySQL 8.0+ 默认 strict mode 下） - 避免用
ELSE 'unknown'这类兜底值，除非业务真需要它；否则掩盖了数据异常
示例：
UPDATE orders SET status = CASE WHEN paid_at IS NOT NULL AND shipped_at IS NULL THEN 'shipped_pending' WHEN shipped_at IS NOT NULL AND delivered_at IS NULL THEN 'delivered_pending' ELSE status -- 关键！保持原值 END WHERE id IN (101, 102, 105);
WHERE条件不能只靠CASE里的判断
有人把状态判断全塞进 CASE，然后 WHERE 1=1，这是危险操作。数据库会扫描全表，即使只有一行满足条件，性能和锁范围都失控。
实操建议：
-
WHERE子句必须提前过滤出可能变更的记录范围，比如按id IN、updated_at 或状态旧值 <code>status IN ('pending', 'paid') -
CASE里的条件只是“在筛选出的行中，具体改成哪个新值”，不是筛选逻辑本身 - 如果要按不同规则更新不同子集（比如部分按时间、部分按用户等级），优先拆成两条
UPDATE，而不是在一个CASE里堆复杂嵌套
PostgreSQL和SQL Server的语法差异点
MySQL 的 CASE 更新写法在其他数据库里基本通用，但有两个关键细节容易翻车：
- PostgreSQL 要求
UPDATE ... SET col = (SELECT ...)形式才能关联子查询，而 MySQL 支持直接CASE；如果跨库迁移，别直接复制粘贴 - SQL Server 中，
CASE表达式里不能出现聚合函数或窗口函数，哪怕外面没分组也不行；MySQL 允许（但不推荐） - 所有数据库对
CASE分支返回类型一致性要求严格：比如一个分支是字符串'active'，另一个是数字1，SQL Server 和 PostgreSQL 会直接报错，MySQL 可能隐式转成字符串但结果不可控
所以写 CASE 时，所有 THEN 后面的值必须是同一类型，宁可显式 CAST('1' AS VARCHAR) 也不要依赖自动转换。
真正麻烦的是状态流转规则变频繁又没配套校验——比如新加一个中间态，但老代码的 CASE 没覆盖，或者 WHERE 条件没同步收紧。这类问题不会立刻报错，但数据会慢慢漂移。上线前最好用 SELECT 把 CASE 逻辑单独跑一遍，核对变更前后分布。
