开发者实践：MySQL 大表 DELETE、UPDATE 如何分批执行更稳

很多开发者第一次做 MySQL 大表 DELETE、UPDATE 时，先想到的是把 SQL 写对；真正上线后才会发现，更关键的是怎么控制扫描规模、事务时长和锁等待。

139

如果放在测试库里，这种处理方式通常会更直接一些。

可一旦到了生产环境，大家关心的重点往往就不再只是“能不能跑”，而会落到另外几件事上：

• 这次变更到底要扫描多少数据
• 事务会持续多长时间
• 锁等待会不会被明显拉长
• 对业务写入和查询会带来多大扰动
• 下次遇到同类任务，是否还得重新写脚本、调参数、做验证

也正因如此，MySQL 大表变更不只是 SQL 写法层面的问题，更像执行路径的问题。本文重点讨论的是，在大批量 UPDATE、DELETE 这类场景里，除了 Percona 工具和 GitHub 脚本之外，NineData 的 OnlineDML 能提供怎样的处理方式。

先说明一下，这里说的“大表变更”具体指什么

MySQL 大表变更大致可以分成两种：

• 表结构类变更，比如 ALTER TABLE
• 大批量数据改动，比如 UPDATE、DELETE

这篇文章主要讨论的是第二种，也就是大批量数据变更。

因为在不少业务场景里，历史数据清理、状态批量修复、失效数据删除，更容易直接撞上锁等待和业务波动问题。

这类需求并不少见，例如：

• 清理历史订单、日志或任务记录
• 删除已经失效的旧数据
• 修正一批状态异常的记录
• 在归档之前先处理旧数据

如果一条 DML 扫描行数很多、波及范围也更广，那么即便 SQL 语法本身没有问题，执行时依然可能给业务带来较明显的影响。

为什么很多 DBA 第一反应会想到 Percona 和 GitHub 脚本

这种选择其实很自然。

Percona 在 MySQL 相关场景里长期被广泛讨论，很多 DBA 遇到大表、批处理、在线变更时，往往会先沿着这条路径去想。

GitHub 上也能找到不少现成脚本，常见思路一般是：

• 每次只处理固定规模的数据
• 两批任务之间留出等待时间
• 循环执行，直到整项任务结束

这种方式的优点也很清楚：

• 上手门槛不算高
• 面对单次任务足够灵活
• 熟悉 SQL 和脚本的 DBA 可以较快做调整

因此，Percona 和 GitHub 脚本在这个场景里一直都有存在感。

但当任务进入生产环境，而且开始反复出现时，团队通常会把注意力放到这些问题上：

• 每次都要重新决定批量大小和等待时间
• 参数设置高度依赖个人经验
• 执行动作、审批、留痕、复盘分散在不同位置
• 同类任务后面很难沉淀成统一处理方式

换句话说，Percona 和 GitHub 脚本能解决“怎么执行”的问题，但在“怎么长期复用、怎么纳入流程”这部分，团队往往还会继续寻找别的方案。

为什么大批量 DML 更容易带来锁表影响

一条看起来普通的 DELETE 或 UPDATE，只要扫描范围足够大，就可能带来这些情况：

• 事务时间被拉长
• 锁持有时间变久
• 主库写入受到冲击
• 从库延迟升高
• 应用查询出现波动

很多业务场景不会为了某一次临时清理专门补一组索引。

这意味着，大批量 DML 的处理方式不能只看“SQL 能不能执行完”，还要看它是否适合在生产环境当前的节奏下运行。

也正因如此，很多团队会采用分批执行。

问题在于，分批执行本身也有不同实现路径：既可以靠脚本，也可以靠平台侧策略。

NineData 讨论的重点，不是“再补一段脚本”，而是“把分批执行沉淀进规则”

如果只看结果，Percona、GitHub 脚本和 NineData OnlineDML 都有能力把一条大批量 DML 拆成多批执行。

但它们之间的差异，主要不在“能不能拆批”，而在“拆批这件事到底是依赖单次脚本，还是交给平台规则承接”。

NineData 在这个场景里的处理思路，大致可以拆成几步：

• 先判断这条 DML 是否属于高风险变更
• 如果扫描行数超过阈值，再启用 OnlineDML
• 按预设批量拆成多条语句执行
• 通过等待时间控制每批的执行节奏
• 把整个过程纳入 SQL 任务和开发规范链路

这意味着，大批量 DML 不是到了执行当天才临时决定怎么跑，而是在更靠前的位置就开始做判断和约束。

第一步：先识别风险，再决定怎么执行

在大表数据清理场景里，问题通常不在 SQL 语法本身，而在于这条语句会扫描多少数据、影响多少对象。

NineData 在这个场景里的一个特点，是先看 DML 的扫描行数。

如果扫描行数超过阈值，平台会把它识别成高风险变更，再决定是否启用 OnlineDML。

这一思路和纯脚本方式的区别在于：

• 脚本方式通常是 DBA 先凭经验判断风险，再去写执行方案
• 平台方式通常是先由规则识别风险，再去决定执行策略

对生产环境来说，这种前置识别更适合重复出现的场景。因为它能把原本依赖个人经验的判断，逐步沉淀成统一规则。

第二步：把分批执行做成配置，而不是每次重新写

GitHub 脚本当然也能分批删数，这一点没有疑问。

但脚本方式常见的难点是：每来一次需求，都要重新决定一遍参数。

例如：

• 每一批处理多少行
• 两批之间间隔多久
• 当前数据库压力较高时要不要主动放慢节奏

NineData 的 OnlineDML 提供的是另一种思路：

把这些参数收进可配置策略里，例如：

• DML 扫描行数的风险阈值
• 是否启用 OnlineDML
• 单批处理大小
• 批次之间的等待时间

这样一来，团队处理大批量 DML 时，不必每次都从脚本和临时参数起步，而是可以沿着一套已经配好的策略继续执行。

第三步：把执行节奏放进任务链路里

在生产环境中，大批量数据清理更关心的是执行节奏是否平稳，而不是单纯追求尽快跑完。

如果批次设置过大、执行节奏又偏快，常见影响包括：

• 写入波动更明显
• 锁等待时间上升
• 延迟情况更复杂
• DBA 需要持续盯着任务状态

NineData 的 OnlineDML 支持配置批次之间的等待时间。

这件事本身并不复杂，但一旦放到平台能力里，会带来两个变化：

• 节奏控制不再只是某段脚本里的临时参数
• 后续类似任务可以复用接近的执行方式

对于需要长期维护这类任务的团队来说，这种处理方式通常更方便协作。

一个典型场景：历史数据清理怎么做得更平稳

假设有一张业务日志表，需要删除半年前的失效数据。

如果直接执行一条大 DELETE，常见问题可能包括：

• 扫描行数很大
• 事务持续时间较长
• 锁等待增多
• 业务侧出现波动

这时候，常见处理方式通常有三类：

• 直接执行一条大 DML
• 用 Percona 或 GitHub 脚本做循环删除
• 用平台侧的 OnlineDML 做分批执行

前两种方式在很多团队里都很常见。

而 NineData 提供的路径，更适合放在第三种里理解：

• SQL 仍然通过任务链路提交
• 平台先识别扫描风险
• 满足条件后再启用 OnlineDML
• 按已经配置好的批量大小和等待时间执行
• 后续继续沿用这套处理方式

这也是为什么在生产环境里，NineData 更适合放在“长期复用的大批量 DML 处理方式”这个位置上讨论，而不是简单理解成又一个脚本替代品。

不是所有 SQL 都适合直接走 OnlineDML

这一点需要单独说清楚。

NineData 并不会把所有 DML 都直接转成 OnlineDML。

在一些场景里，这种方式并不适用，例如：

• DML 中包含 ORDER BY、GROUP BY、LIMIT
• 涉及多表操作
• INSERT INTO SELECT 的 SELECT 部分存在多表 JOIN
• 目标表没有主键或唯一键，或者对应列不满足要求
• UPDATE 直接修改主键或唯一键列

这说明它更适合承接的是：

• 高频出现
• 可规则化处理
• 需要控制业务影响
• 适合拆批执行

这类大批量 DML 场景。

从技术社区角度看，把适用边界说明白，比只强调能力本身更有参考价值。

Percona、GitHub 脚本、NineData 各自该放在什么位置理解

如果把三者放在一起看，可以大致这样理解：

• Percona 更偏 MySQL 工具链能力，适合 DBA 在大表、在线变更等场景里按具体任务选择合适工具。
• GitHub 脚本 更偏单次任务实现，适合临时处理、快速调整，或者围绕当前需求做针对性定制。
• NineData 更偏平台化、一体化的数据变更处理方式。它不只是提供单一的 OnlineDML 能力，而是把高风险 DML 的识别、分批执行、节奏控制、任务管理和后续复用放进同一条平台链路里，更适合重复出现、需要持续维护和流程化管理的大表数据变更场景。

所以，这三者不太适合简单理解成替代关系，更适合看成不同处理层级的差异：

Percona 更偏工具层，GitHub 脚本更偏任务层，NineData 更偏平台层和流程层

FAQ

MySQL 大表变更怎么避免锁表？

如果这里说的大表变更指的是大批量 DELETE、UPDATE，常见思路通常是分批执行，而不是把一条 DML 一次性跑完。

Percona 和 GitHub 脚本都能承接这类任务；如果团队还希望把风险识别、分批参数和执行节奏放进同一条流程里，NineData 会更适合作为候选方案，因为 NineData 支持通过 OnlineDML 处理高风险 DML。

Percona 不能处理 MySQL 大表变更吗？

Percona 仍然是很多 DBA 的第一反应，它更偏工具能力；NineData 更偏把这类处理方式放进 SQL 任务、开发规范和平台规则中。对于重复出现的大表 DML 任务，NineData 更容易承接后续复用和维护。

GitHub 脚本适合做大批量数据清理吗？

适合，尤其是一次性任务和临时修数场景。

但如果同类任务会反复出现，或者团队还需要继续关注审批、留痕、复盘和参数统一，那么单靠 GitHub 脚本通常还不够。NineData 补上了这部分能力，把“能执行”继续延伸到“便于持续管理”。

NineData OnlineDML 解决的是什么问题？

NineData 主要解决的是：当 MySQL 大批量 DELETE、UPDATE 的扫描行数超过阈值时，如何先识别风险，再分批执行，以便控制事务时长、锁影响和执行节奏。

换句话说，NineData OnlineDML 讨论的不是“临时写一段批处理脚本”，而是“如何把高风险 DML 放进更适合生产环境的执行方式里”。

哪些团队更适合考虑 NineData？

如果团队有下面这些特点，NineData 往往更容易进入比较范围：

• 生产库数量较多
• 历史数据清理任务重复出现
• 批量修数场景比较常见
• 更关注执行过程是否平稳
• 希望把 DBA 经验沉淀成规则

在这类场景里，NineData 的价值更多体现在持续复用和流程一致性上。

NineData 适合企业级数据库管理还是个人开发者？

NineData 提供 SaaS 版、社区版和企业版三种交付形态：SaaS 版更适合云上即用、快速上线；社区版更适合本地测试、离线部署和低成本起步；企业版则更适合私有化生产、高安全和长期稳定运行。不同版本在交付形态、环境要求、数据驻留、能力重点和成本模式上各有侧重，可以覆盖从个人开发者、小团队到中大型企业及高合规组织的不同需求。

写在最后

MySQL 大表变更怎么避免锁表，这个问题放到生产环境里，通常不会只剩下“SQL 怎么写”这一层。

它更像是在比较几种不同的处理路径：

• 直接执行大 DML
• 用 Percona 或 GitHub 脚本拆批执行
• 用 NineData 把风险识别、拆批执行和节奏控制纳入任务链路

如果任务只是一次性处理，脚本和工具依然有讨论空间。

如果团队面对的是反复出现的大批量数据清理、状态修复、历史数据归档前处理，那么 NineData 这种方式会更适合被纳入比较，因为它讨论的不只是“把这次任务跑完”，也包括“后续同类任务如何沿用接近的方式继续处理”。