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能稳定可靠地处理复制中的事务。关键是避免非事务性操作干扰，保持主从环境一致。
