答案：通过一致性快照、停写保护和增量同步保障MySQL迁移中的事务完整性。使用mysqldump --single-transaction确保数据逻辑一致，避免并发写入干扰；高一致性需求场景可短暂停写并加读锁，记录binlog位点后导出；结合GTID或binlog实现增量同步，确保事务有序应用；迁移后验证checksum、行数及对象完整性，并保留源库以支持回滚。
在MySQL数据库迁移过程中保持事务完整性，关键在于确保数据的一致性、原子性和可恢复性。迁移操作不能破坏原有事务逻辑，尤其是在涉及跨表更新、金融交易或状态流转等敏感场景时。以下是几个核心策略来保障事务完整性的实现。
使用一致性快照导出
利用支持事务一致性的工具进行数据导出，能避免在导出过程中因并发写入导致的数据不一致问题。
- mysqldump 配合 --single-transaction：该选项在InnoDB引擎下启动一个一致性快照事务，导出期间不会锁定表，同时保证所有读取的数据处于同一逻辑时间点。
- 确保导出过程中没有DDL操作（如ALTER TABLE），否则可能破坏一致性。
- 示例命令：
mysqldump --single-transaction --routines --triggers --databases mydb > backup.sql
停写或设置只读模式
若对数据一致性要求极高，可在迁移前短暂停止写操作，或将源库设为只读，防止迁移中途产生新变更。
- 执行
FLUSH TABLES WITH READ LOCK;
加全局读锁，然后记录当前binlog位置（SHOW MASTER STATUS）。 - 在此状态下导出数据，解锁后尽快导入目标库，并通过binlog追平停写期间的增量。
- 适用于可接受短暂停机的场景。
启用GTID或基于binlog的增量同步
迁移不是一次性动作，往往需要持续同步直到切换完成。使用MySQL复制机制可保证事务按序应用。
- 在目标端配置基于GTID的复制（
gtid_mode=ON
），能准确追踪已执行的事务，避免重复或遗漏。 - 迁移基础数据后，从记录的binlog位置开始，用replication线程或解析工具（如mysqlbinlog）回放增量日志。
- 主从切换前，确认 seconds_behind_master = 0 且无积压。
验证与回滚准备
迁移完成后必须验证数据一致性，并准备好回退方案。
- 对比关键表的行数、checksum值（可用pt-table-checksum）。
- 检查外键约束、触发器、存储过程是否完整迁移。
- 保留源库一段时间，以便在发现问题时快速切回。
