MySQL中批量更新不同行不同值的唯一可靠方案是CASE WHEN，需满足三条件：明确指定目标表、WHEN分支THEN值类型一致、必须有WHERE限定范围；否则可能静默失败或性能骤降。
UPDATE 中的 CASE WHEN 语法结构必须匹配字段类型
直接在 UPDATE 语句里用 CASE WHEN 实现动态更新是可行的，但关键在于：每个 WHEN 分支返回的值必须和目标字段类型兼容，否则会触发隐式转换失败或截断（比如对 INT 字段返回字符串）。数据库不会自动帮你“猜意图”。
常见错误现象：ERROR: column "status" is of type integer but expression is of type text —— 这通常是因为某个 THEN 返回了字符串，而字段是数字类型。
- 所有
THEN和ELSE的表达式结果类型要一致，优先显式转换，例如用CAST('1' AS INTEGER)或::INTEGER - 避免混合返回
NULL和字符串，尤其当字段定义为NOT NULL时，ELSE NULL可能导致违反约束 -
ELSE子句强烈建议显式写出，不依赖默认NULL，便于追踪逻辑覆盖是否完整
WHERE 条件不能省，否则容易全表误更新
CASE WHEN 本身不控制影响行数，它只决定“更新成什么”，真正决定“更新哪些行”的是 WHERE。漏写或写错 WHERE 是线上事故高频原因。
使用场景：批量修正状态、按条件分级更新积分、根据时间窗口切换开关字段等。
- 务必先用
SELECT验证WHERE范围，例如：SELECT id, status, CASE WHEN ... END AS new_status FROM orders WHERE updated_at - 如果业务上需要“无条件更新”，也请显式写成
WHERE TRUE或WHERE 1=1，避免后期误删条件后静默全表更新 - 涉及多条件分支时，
WHERE可前置过滤大范围，减少CASE计算开销（尤其在千万级表上）
嵌套 CASE 或联合多个字段更新要注意执行顺序
一个 UPDATE 语句中可以同时更新多个字段，每个字段都可以有自己的 CASE WHEN，但它们是并行计算的，不相互依赖 —— 即字段 A 的新值不能基于字段 B 在同一条语句中刚被更新的值（那是两阶段逻辑，需拆成两个语句或用 CTE）。
性能影响：多字段 + 多层嵌套 CASE 会增加解析与执行成本，PostgreSQL 和 MySQL 8.0+ 优化较好，但 SQLite 或旧版 MySQL 可能退化明显。
- 避免三层以上嵌套
CASE WHEN，可提取共用逻辑到子查询或 CTE 中 - 更新
created_at、updated_at等时间戳时，不要写成CASE WHEN ... THEN NOW() ELSE created_at END——NOW()在整条语句中只求值一次，不是每行独立调用 - 若需“仅当某字段变化时才更新时间戳”，得用
WHERE old_value != new_computed_value配合条件，不能靠CASE内部判断
MySQL 与 PostgreSQL 在 NULL 处理上的细微差异
两者都支持标准 CASE WHEN，但在边界情况表现不同：比如 WHEN col = NULL 永远不成立（要用 IS NULL），这点一致；但 MySQL 对空字符串 '' 和 NULL 的隐式比较更宽松，PostgreSQL 更严格。
错误示例：WHEN name = '' THEN 'anonymous' 在 PostgreSQL 中没问题，但在某些 MySQL 排序规则下可能因字段带 CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_as_cs 导致大小写敏感匹配失败。
- 跨数据库迁移时，统一用
WHEN name IS NOT DISTINCT FROM ''（PostgreSQL）或WHEN COALESCE(name, '') = ''（兼容 MySQL）来安全判空 - MySQL 5.7 默认开启
STRICT_TRANS_TABLES前，CASE返回超长字符串可能被静默截断；建议始终在测试环境开启严格模式验证 - PostgreSQL 中
CASE表达式可直接用于RETURNING子句，MySQL 不支持，需额外SELECT查询确认结果
实际最易被忽略的是：CASE WHEN 更新后的值，在同一事务中后续语句读到的是新值，但触发器（如 BEFORE UPDATE）看到的是旧值 —— 如果业务逻辑混用了触发器和 CASE 动态更新，这里很容易出现预期外的行为偏移。
