线上跑一条 UPDATE，审批到底该走几步？聊聊数据订正流程的「最小必要集」

背景

我做了 8 年运维，其中 5 年在一家 200 人的互联网公司负责核心业务线的运维和 DBA 协作。数据订正（线上跑 UPDATE / DELETE）是我日常打交道最高频的"危险操作"之一。

热榜上大家在聊连接池、超时重试、mTLS 证书轮换，都是"系统级"的稳定性话题。但我在一线值班时发现：真正炸掉生产库的，十有八九不是架构问题，而是一条"看起来很简单"的 UPDATE。 去年我们一条改用户状态的 UPDATE 因为 WHERE 条件漏了 AND status != 0，直接刷了 1.2 亿行，InnoDB 锁等待雪崩，下游 3 个服务全部超时，P99 从 80ms 飙到 14s，持续 42 分钟才恢复。复盘时开发同学说"我本地 test 环境跑过没问题"——test 环境只有 3 万行。

常见分歧（三套流程，各有拥趸）

我见过至少三套完全不同的数据订正流程，每套都有人觉得"太松"或"太重"：

① 极简派：DBA review → 直接执行。 开发提工单，DBA 看一眼 SQL，没问题就跑。整个流程 10 分钟闭环。

优势：快，开发不烦。 代价：我上面那个 1.2 亿行的事故就是这么来的。DBA 看了 SQL 觉得"逻辑没问题"，但没跑 SELECT COUNT(*) 验证影响行数。

② 标准派：提需求 → 写 SQL → DBA review → 测试环境验证 → 主管+DBA 双签 → 执行窗口 → 执行 → 验证行数。 流程 7 步，走下来 1~2 天。

优势：每一步都有人兜底，出事能追溯到具体环节。 代价：开发开始绕流程。我亲眼见过一个开发"先跑再说"，跑完才补工单。

③ 平台派：数据订正做成平台功能。 开发在界面上填条件、设行数上限、选执行窗口，系统自动生成 SQL + dry-run（SELECT COUNT(*) + EXPLAIN），DBA 异步审批，执行后自动校验受影响行数与预期是否一致。

优势：规则写死在系统里，不依赖人的自觉。 代价：建设周期 2~3 个月，建设期间还是回到人工流程。而且我见过一个平台上线 4 个月后，DBA 审批变成了"橡皮图章"——因为系统已经拦住了大部分风险，DBA 不再认真看了。

我的倾向与理由

我倾向于**"分级 + 平台兜底"**的组合，核心原则只有一条：流程的步数不该是固定的，应该由数据量和影响面决定。

具体我建议一个"三档分级"：

| 档位 | 触发条件 | 必要步骤 | 闭环时间 | |------|---------|---------|---------| | L1 | 影响 < 100 行，单表，WHERE 含主键或唯一索引 | DBA 单人 review + SELECT COUNT(*) 验证 + 执行 | 10 分钟 | | L2 | 影响 100~10000 行，或涉及多表 JOIN / 子查询 | DBA review + 主管审批 + 测试环境验证 + 执行窗口 | 1 天 | | L3 | 影响 > 10000 行，或涉及核心交易表 / 分库分表 / 无索引全表扫描 | DBA + 主管 + 架构师三方审批 + 分批执行（每批 ≤ 5000 行）+ 逐批校验 + 回滚预案 | 3 天 |

关键点：

1. SELECT COUNT(*) 验证影响行数是 L1 的最低门槛，没有这一步，DBA review 等于没做。我见过太多"SQL 逻辑正确但 WHERE 条件在目标数据分布下命中量超预期"的案例。
2. L3 必须分批。一条 UPDATE ... WHERE merchant_id = 12345 如果命中 800 万行，InnoDB 会一次性生成 800 万行 undo log，redo log 写满，主从延迟直接拉到 30 分钟以上。分批 5000 行 + SLEEP(1) 是我最保守的默认参数，具体步长要看表大小和从库延迟。
3. 回滚预案不是"事后补"，是"执行前必须填"。L2 以上没有回滚 SQL 的工单一律打回。回滚 SQL 不是 UPDATE ... SET old_value，而是执行前先 CREATE TABLE t_backup AS SELECT ... WHERE ...，这一步 30 秒搞定，但能救命。

想听大家

1. 你们团队的数据订正流程到底走几步？从"开发提需求"到"SQL 跑完"平均多长时间？
2. 有没有遇到过"流程太重 → 开发绕流程"的情况？你们怎么处理的——是加监控还是简化流程？
3. 你们用什么工具承载（Jira 工单 / 自研平台 / DBA 手动跑）？有没有人真的把"行数上限 + dry-run + 自动校验"做成平台功能了？效果如何？
4. 如果让你设计一个"最小必要集"的审批流程，你会保留哪几步、砍掉哪几步？为什么？

抛砖引玉，期待不同规模团队（3 人小团队 vs 200 人大团队）的对比视角。