标准答案
- 先写只读 SELECT 验证筛选条件、受影响行数和样本，必要时由业务方确认目标范围。
- 修复语句应带明确主键范围、当前状态和版本条件，重复执行不应再次改变已修复记录。
- 大批量修复按小批次执行，控制事务大小、速率和观察窗口，避免长事务、复制延迟与锁积压。
- 记录操作者、工单、脚本版本、输入参数、每批结果和异常，便于审计与重放。
- 提前准备回滚数据、反向操作或可重建来源，并在执行后验证业务不变量和相关下游。
题目解析
直接在线 UPDATE 的危险在于范围和可逆性。一个少写租户条件的脚本可能修改全表；一个错误表达式可能立刻覆盖原值；一个大事务还会阻塞正常业务，让排查和回滚更难。
幂等不等于永远不改。它要求同一脚本在同一目标上重复运行后结果稳定。通常通过旧状态、版本号、迁移标识或修复记录保证，而不是只依赖“应该只执行一次”。
代码示例
先预览并按批次、旧状态和审计条件修复，受影响行数应与预期对账。
sql
-- 预览：确认范围和样本
SELECT id, status
FROM orders
WHERE tenant_id = ? AND status = 'stuck'
ORDER BY id
LIMIT 100;
-- 批次修复：仅修改仍处于目标旧状态的记录
UPDATE orders
SET status = 'cancelled', updated_at = CURRENT_TIMESTAMP
WHERE tenant_id = ?
AND id > ? AND id <= ?
AND status = 'stuck';常见误区
- 没有预览和行数上限，直接运行全表 UPDATE 后才发现条件写错。
- 只记录“脚本执行成功”，没有保留受影响 ID、版本和回滚依据。