MySQL通过binlog记录事务，以ROW模式推荐确保安全；主库dump线程推送事件至从库IO线程，写入relay log，SQL线程串行重放，支持多线程提升性能；GTID实现全局事务唯一标识，保障一致性与自动定位；配合正确配置可稳定复制。
MySQL在主从复制中处理事务时，依赖二进制日志（binary log）和复制线程机制来确保数据一致性。核心在于事务的记录方式、传输过程以及在从库上的重放机制。下面介绍MySQL复制中事务的处理方法。
事务如何被记录到二进制日志
当主库执行事务时，是否写入二进制日志取决于存储引擎和事务提交方式：
- InnoDB等支持事务的引擎，在事务提交时将更改写入binlog（前提是开启了binlog）
- binlog格式决定了事务如何被记录：STATEMENT、ROW 或 MIXED
- 推荐使用ROW模式，它记录每一行数据的变更，更安全且避免因函数或非确定语句导致主从不一致
- 事务在binlog中以“事件”形式存在，包括begin、write row、update row、commit等
复制线程如何传输事务
MySQL复制通过三个关键线程协作完成事务传递：
- Dump Thread（主库）：监听binlog变化，将事务事件发送给从库
- IO Thread（从库）：接收主库发来的binlog事件，并写入本地中继日志（relay log）
- SQL Thread（从库）：读取relay log中的事务事件并按顺序重放，实现数据同步
事务在从库的重放是串行执行的，默认情况下一个SQL Thread逐条应用，保证顺序性但可能成为性能瓶颈。可启用多线程复制（如slave_parallel_workers > 0）提升效率。
GTID与事务一致性保障
MySQL 5.6+引入GTID（全局事务标识符），简化了事务追踪和故障恢复：
- 每个事务拥有唯一GTID，格式为server_uuid:transaction_id
- 从库通过GTID自动识别已执行的事务，避免重复或遗漏
- 切换主从或重建复制时无需手动找位点，只需CHANGE MASTER TO MASTER_AUTO_POSITION = 1
- 开启GTID需设置gtid_mode=ON并配置enforce_gtid_consistency=ON
复制中的事务冲突与错误处理
尽管MySQL尽力保证一致性，但在网络延迟、主库崩溃或人为操作下仍可能出现问题：
- 若从库执行事务时报错（如主键冲突），复制会中断，需人工干预或跳过错误
- 可通过设置sql_slave_skip_counter临时跳过事务，但有风险
- 使用Replication Filters时要谨慎，避免因过滤导致事务逻辑断裂
- 建议开启sync_binlog=1和innodb_flush_log_at_trx_commit=1增强持久性
基本上就这些。只要合理配置binlog格式、启用GTID并监控复制状态，MySQL能稳定可靠地处理复制中的事务。关键是避免非事务性操作干扰，保持主从环境一致。
