MySQL通过两阶段提交、行级锁、RBR+GTID模式协同保障主从复制一致性：事务先写redo log并预提交，再写binlog后正式提交，确保崩溃恢复时数据一致；InnoDB行锁与间隙锁控制并发，避免脏读与幻读，但长事务易导致从库延迟；RBR记录行变更而非SQL语句，较SBR更安全，结合GTID实现事务唯一标识，确保主从精准同步，推荐RC或RR隔离级别下使用RBR+GTID以平衡性能与一致性。
MySQL 中的锁机制和事务管理在主从复制环境中协同工作，确保数据一致性与并发性能。核心在于事务提交时产生的二进制日志（binlog）如何被安全地记录并应用到从库，同时避免因锁冲突或并发操作导致的数据不一致。
事务与 binlog 的一致性保障
在使用 InnoDB 存储引擎的 MySQL 实例中，事务提交过程与 binlog 写入通过两阶段提交（2PC）机制协调，确保崩溃恢复后主库和从库状态一致：
- prepare 阶段：InnoDB 将事务的修改写入 redo log 并标记为 prepare 状态，此时事务尚未提交。
- commit 阶段：MySQL 将该事务的 binlog 写入文件并同步到磁盘，随后 InnoDB 提交事务，更新 redo log 为 commit 状态。
这种机制保证了即使发生崩溃，恢复时也能根据 binlog 和 redo log 的状态决定是否重做或回滚事务，从而保持主从复制的数据一致性。
锁机制对复制行为的影响
InnoDB 使用行级锁、间隙锁等机制控制并发访问，在复制场景下这些锁会影响事务的执行顺序和 binlog 记录内容：
- 读写操作在事务中加锁，防止其他事务修改相同数据，这会延迟某些语句的执行，间接影响 binlog 中事件的时间分布。
- 长时间持有锁的事务可能导致主库上大量事务堆积，进而造成从库延迟（replication lag），因为从库需按主库提交顺序依次应用事件。
- 在 RC（Read Committed）隔离级别下，间隙锁减少，提升了并发性，但可能增加幻读风险；RR（Repeatable Read）则更严格加锁，有助于逻辑一致性，但也更容易引发锁等待。
不同复制模式下的事务处理方式
MySQL 支持基于语句（SBR）、基于行（RBR）和混合模式（MBR）三种 binlog 格式，它们对事务和锁的处理有显著差异：
- SBR（Statement-Based Replication）：记录 SQL 语句本身。若语句涉及非确定性函数（如 NOW()），可能导致主从数据不一致。此外，UPDATE 加锁范围依赖语句执行计划，从库执行时加锁行为可能不同。
- RBR（Row-Based Replication）：记录每一行的实际变化（before/after image）。这种方式精确反映事务影响，避免了 SBR 的不确定性问题，且能更准确还原主库的锁影响效果，推荐用于复杂事务环境。
- MBR（Mixed-Based）：自动选择 SBR 或 RBR，兼顾效率与安全，但在某些边缘情况下仍需人工干预确认格式选择。
GTID 与事务原子性增强复制可靠性
全局事务标识符（GTID）将每个事务标记为唯一 ID，简化故障切换和数据校验：
- 每个事务在主库生成唯一的 GTID，从库通过 GTID 自动识别已执行事务，避免重复或遗漏。
- 结合 binlog 和 relay log，GTID 能精准定位复制位置，即使主库重启或发生切换，也能快速恢复同步。
- 启用 GTID 后，要求事务必须完全写入 binlog 才能提交，进一步强化了锁、事务与复制的一致性链条。
基本上就这些。MySQL 通过事务两阶段提交、合理的锁策略、合适的 binlog 格式以及 GTID 技术，使锁和事务能在复制过程中协同运作，既保证数据一致性，又维持系统可用性与性能。配置时建议使用 RBR + GTID 模式，并合理设置隔离级别以平衡并发与一致性需求。
