一、无死锁跨库数据迁移的最优方案 #

结合你提到的Database A被24×7机器人持续访问的场景，这几个实战验证过的方案可以优先考虑：

• 分批增量迁移（分块处理）
  别直接用全量insert into select，把数据拆成小批次迁移。比如按主键ID或时间戳分段，每次只处理1000-5000条，示例语句如下：

  INSERT INTO DatabaseB.table1 (col1, col2)
  SELECT col1, col2 FROM DatabaseA.table1
  WHERE id BETWEEN 1 AND 1000;
  COMMIT;
  

  每批执行完就提交事务，锁的范围极小，不会长时间占用资源，和机器人的并发冲突概率会大幅降低。如果迁移过程中有新数据写入，最后再做一次增量同步——记录下最后一批迁移的ID/时间戳，只同步之后新增的数据即可。

• 利用只读副本/快照迁移
  如果Database A有只读副本，直接从副本拉数据迁移，完全不影响主库的机器人访问。要是没有副本，很多数据库支持创建在线快照（比如MySQL用mysqldump --single-transaction导出，SQL Server创建数据库快照），基于快照迁移数据，主库业务不受任何干扰。

• CDC（变更数据捕获）实时同步
  用Canal、Debezium这类CDC工具，实时捕获Database A中两张表的增删改操作，异步同步到Database B。这种方式属于增量同步，不会一次性锁定大量数据，完美适配24×7不间断访问的场景，甚至能做到近乎实时的同步，后续还能持续维护数据一致性。

• 低峰期全量迁移+增量补同步
  如果能找到业务低峰窗口（比如凌晨2-4点），先在低峰期快速完成全量迁移，然后记录迁移完成的时间点，同步这个时间点之后产生的增量数据。这种方式适合数据量不大、低峰期能腾出时间的场景，全量迁移时锁的时间短，冲突概率极低。

二、预知脚本触发死锁的相关设置 #

如果一定要用insert into select这类语句，提前做这些设置来降低死锁风险：

• 调整事务隔离级别
  把事务隔离级别从默认的「可重复读（RR）」降到「读已提交（RC）」，很多数据库（比如MySQL）在RC级别下不会加Gap锁，锁的粒度更细，能减少死锁的发生。执行语句：

  SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
  

  之后再执行迁移脚本即可。

• 设置锁超时时间
  给数据库设置合理的锁等待超时，比如MySQL中：

  SET innodb_lock_wait_timeout=10; -- 单位：秒
  

  这样如果迁移语句遇到锁等待，超过10秒就会自动放弃，不会一直占用资源导致死锁。

• 确保使用行级锁引擎
  如果你用的是MySQL，一定要确保两张表都是InnoDB引擎（MyISAM是表级锁，极易引发死锁）。InnoDB的行级锁能把锁的范围缩小到单行，冲突概率大幅降低。

• 统一操作顺序
  如果迁移涉及多张表，尽量和机器人访问的操作顺序保持一致。比如机器人总是先操作table1再操作table2，那迁移时也先迁table1再迁table2，避免循环等待导致的死锁。

• 开启死锁日志排查
  提前开启死锁日志，方便后续排查具体冲突点。比如MySQL中：

  SET GLOBAL innodb_print_all_deadlocks=ON;
  

  这样死锁发生时，日志会详细记录锁的持有和等待情况，能帮你针对性优化脚本。

内容的提问来源于stack exchange，提问作者pankaj