标准答案
- 修复前明确业务原因、影响范围、选择条件、预期行数和数据来源，并让相关业务方复核。
- 脚本应支持 dry-run、幂等执行、分批限速、事务边界和详细审计，避免一次性修改不可控的大量数据。
- 先在隔离环境或小流量样本上验证，再在生产按批次执行并实时检查行数、错误率和关键业务指标。
- 回滚方案需要在执行前准备，包括备份、反向操作、版本记录和停止条件，不能等出错后临时拼凑。
题目解析
临时手工 SQL 往往缺少条件、日志和复核，最危险的是“看起来只影响几行”的误判。数据一旦被下游同步或用户读取，恢复成本会急剧上升。
幂等让脚本可安全重跑，但不代表可以忽略业务状态。修复逻辑仍要遵守状态机、权限和时间窗口。
常见误区
- 在生产直接执行没有 WHERE 预览的 UPDATE 或 DELETE。
- 修复脚本不可重跑，失败后无法判断哪些数据已经变更。
- 只验证数据库行数，不验证业务页面、消息和对账结果。