不能直接用UPDATE，须分三步：先SELECT验证逻辑，再事务包裹批量操作，最后加校验回滚点；因业务变更致字段语义迁移，直接UPDATE易引发旧值映射不唯一、关联字段未同步、约束冲突静默失败等问题。
直接结论：不能靠一条UPDATE硬上，必须分三步走——先用SELECT验证逻辑、再用事务包裹批量操作、最后加校验回滚点。
为什么不能直接写 UPDATE ... SET ... WHERE ...？
业务逻辑变更常伴随字段语义迁移（比如status从“0=待处理/1=完成”变成“0=草稿/1=审核中/2=已发布”），直接UPDATE会忽略三类风险：
- 旧值映射关系不唯一：status=1可能对应新逻辑里的多个状态，需结合create_time或order_type判断
- 关联字段未同步：只改status但没更新对应的updated_by或updated_at，导致审计链断裂
- 约束冲突被静默吞掉：比如新状态值超出CHECK约束范围，MySQL可能截断或报错中断，Oracle默认转成NULL
如何安全生成带条件的批量UPDATE语句？
核心是把“业务规则”翻译成可执行的SQL条件树，而不是人工拼字符串。以Oracle为例：
- 用WITH子句预计算映射关系：
WITH status_map AS (SELECT '1' old_val, '2' new_val, 'publish' reason FROM DUAL UNION ALL SELECT '0', '0', 'draft' FROM DUAL) - JOIN原表做精准匹配：
UPDATE target_table t SET status = (SELECT new_val FROM status_map s WHERE s.old_val = t.status AND s.reason = 'publish') - 必须加WHERE限定范围：
WHERE t.status IN ('0','1') AND t.create_time ，避免影响新数据
事务里怎么控制批量提交避免锁表？
Oracle和SQL Server默认事务粒度是语句级，但大批量UPDATE容易触发锁升级（行锁→页锁→表锁）。正确做法：
- 拆成
FORALL循环（Oracle）或WHILE分页（SQL Server），每次处理1000行 - 每批后显式
COMMIT，但注意：中间出错时无法自动回滚整批，得自己建保存点 - 更稳妥的是用
SAVEPOINT sp1+ROLLBACK TO sp1，比如在每100行后设一个 - MySQL 8.0+可用
SET SESSION innodb_lock_wait_timeout = 30防死锁，但别调太低否则误杀正常事务
执行后怎么确认没漏改或错改？
校验不是跑一遍COUNT(*)，而是检查三类边界：
- 查漏：
SELECT COUNT(*) FROM target_table WHERE status IN ('0','1') AND create_time —— 这个数必须等于UPDATE返回的行数 - 查错：
SELECT * FROM target_table WHERE status NOT IN ('0','1','2') AND create_time —— 看有没有意外值残留 - 查关联：
SELECT t.id, u.username FROM target_table t JOIN user_table u ON t.updated_by = u.id WHERE t.status = '2' AND u.status != 'active'—— 验证外键一致性
最容易被忽略的是时间窗口问题：业务系统可能正在写入，你刚UPDATE完，另一条INSERT就带着旧status进来了。所以重构窗口必须和业务停写期对齐，或者用应用层开关冻结写入。
