MySQL 数据迁移实战：如何安全使用 INSERT INTO ... SELECT 避免锁表风险

深入解析：为何 INSERT INTO ... SELECT 在 RR 级别下会锁定全表

许多数据库管理员都曾经历过这样的困境：在 MySQL 默认的可重复读（Repeatable Read，RR）隔离级别下，执行一条INSERT INTO ... SELECT语句，可能导致整个源表被锁定，业务陷入停滞。其根本原因在于 MySQL 的临键锁（Next-Key Lock）机制。该机制不仅会锁定SELECT语句扫描到的所有记录行，还会锁定这些记录之间的间隙。即使你计划仅迁移十万条数据，若查询条件覆盖了一个包含百万数据的主键范围，那么整个区间都可能被锁定，从而阻塞其他事务。

风险更高的场景是，当SELECT查询未能利用主键或唯一索引，而是进行了全表扫描或使用了二级索引时，锁定的范围将变得难以预测和掌控，系统风险显著增加。

为了有效规避这一风险，建议遵循以下核心操作准则：

• 在执行前，务必使用EXPLAIN命令分析SELECT部分的执行计划，确认其是否高效使用了主键或唯一索引。若未使用，应优先考虑优化查询语句或创建合适的索引。
• 尽可能避免在业务流量高峰期执行此类批量数据操作。若无法避开，一个可行的方案是临时将事务隔离级别切换为读已提交（READ COMMITTED），但需评估业务逻辑是否能接受由此可能产生的幻读现象。
• 需要特别警惕的是，在autocommit=0的手动长事务中执行此类语句是高风险操作，因为锁会持续持有直至事务结束，极大地延长了阻塞时间。

分批次数据插入的核心策略：WHERE、LIMIT 与 ORDER BY 的协同

鉴于单次大批量操作的风险，采用分批次处理成为必然选择。然而，简单的分页方式并不可靠。例如，仅使用LIMIT 1000进行分页，若源表在迁移期间有并发写入，基于OFFSET的偏移可能导致数据重复处理或遗漏。

正确的方法是依赖一个有序且稳定的字段（通常是自增主键id）作为分批推进的锚点。核心逻辑是：记录上一批次处理完成的最大id值，并将其作为下一批次查询的起始条件。

以下是一个推荐的安全写法示例：

INSERT INTO target_table (col1, col2) SELECT col1, col2 FROM source_table WHERE id > 100000 AND id <= 101000 ORDER BY id;

实施分批次迁移时，需关注以下关键细节：

• WHERE条件必须与ORDER BY id配合使用，以确保每次查询的结果集顺序严格一致，避免数据错乱。
• 批次大小的设定是一门平衡艺术。建议将单次处理行数控制在500至5000条之间。批次过小会导致事务和网络开销过大；批次过大则会增加单次操作的锁持有时间和内存消耗。
• 关键步骤：务必记录每一批次实际插入数据中的最大id值（注意是本次查询结果集的最大值，而非全表最大值），并将其作为下一轮循环的WHERE条件起点。
• 若目标表可能已存在部分数据，可考虑使用INSERT IGNORE或ON DUPLICATE KEY UPDATE语法处理冲突。但需注意，这些操作在遇到唯一键冲突时，同样会对目标表的相应记录加锁。

优化迁移节奏：如何避免对主从库造成过大压力

成功实施分批次迁移后，另一个常被忽视的关键点是操作频率的控制。高频的小批次插入，虽然对主库的瞬时压力看似不大，却可能产生连锁副作用：频繁的事务提交会急剧增加二进制日志（binlog）的写入量，可能导致从库的 SQL 线程应用延迟，甚至引发主库出现innodb_log_waits等待事件。

因此，科学地控制迁移节奏至关重要：

• 在每批次插入操作完成后，主动引入一个短暂的休眠间隔，例如执行SELECT SLEEP(0.1);。这0.1秒的停顿能有效缓解 I/O 和锁资源的竞争。
• 持续监控SHOW PROCESSLIST的输出。如果出现大量Waiting for table metadata lock状态，这是一个明确的警告信号，表明当前操作频率过高或存在长事务阻塞。
• 密切监控从库的复制延迟。一旦延迟增长，应立即降低迁移频率或暂停操作。使用如pt-heartbeat等专业工具可以更精确地测量复制延迟。
• 必须坚守的原则：为了提升迁移速度而将innodb_flush_log_at_trx_commit参数设置为2（仅写入系统缓存）的做法，仅限于非生产测试环境。在生产系统中，绝不能以牺牲数据持久性和安全性为代价来换取速度。

隐藏的锁风险：唯一索引与间隙锁的相互作用

即使你已严格按照主键进行分批查询，仍可能陷入另一个“锁陷阱”。如果目标表上存在非主键的UNIQUE唯一索引，那么在INSERT每一行数据时，MySQL 不仅会锁定该行记录，还会对这个唯一索引值“理论应处位置”的前后间隙施加间隙锁（Gap Lock）。

这会引发何种问题？它可能与那些正在操作相邻唯一键值的业务 SQL（例如UPDATE ... WHERE unique_col = ?）产生隐式的死锁。错误日志通常仅提示“Deadlock found”，给问题排查带来很大困难。

如何排查并规避这类隐蔽的锁冲突？

• 在开始迁移前，首先使用SHOW CREATE TABLE target_table;命令仔细审查目标表的所有UNIQUE约束。如果存在非主键的唯一索引，可以评估是否能在业务低谷期临时删除（DROP）该索引，待数据迁移完成后再重建（ADD）。这是从根本上避免相关间隙锁冲突的有效方法。
• 善用information_schema数据库中的INNODB_TRX（当前运行事务）和INNODB_LOCK_WAITS（锁等待）表进行实时监控，它们是定位复杂锁问题的强大工具。
• 在预定的数据迁移窗口期内，应尽量避免或严格审查那些会对目标表唯一索引字段进行操作的并发 DML 语句，这些操作是触发间隙锁冲突的主要源头。

总而言之，分批迁移的逻辑本身并不复杂，真正的挑战在于锁的传播路径具有隐蔽性。一旦涉及唯一索引、二级索引扫描，或在迁移过程中存在并发数据修改，锁的行为就会变得复杂且反直觉。因此，最稳妥的建议是：在正式执行生产环境的数据迁移前，务必在测试环境中，使用接近真实的数据量和并发压力，完整地演练整个流程，提前发现并解决潜在问题。