MySQL主从复制是基于binlog日志的异步数据同步机制，依赖主库Dump线程推送、从库I/O线程拉取中继日志、SQL线程串行回放三者协作，非实时镜像，存在延迟与最终一致性。
MySQL 主从复制本质是日志驱动的数据同步机制，核心靠 binlog + 三个关键线程 协同完成，不是实时“镜像”，而是“重放变更”。它不依赖网络直连表数据，而是基于事务日志的异步追加与执行。
binlog 是复制的源头和唯一依据
主库所有写操作（INSERT/UPDATE/DELETE/DDL）都会按事务提交顺序写入二进制日志（binlog）。这个日志必须显式开启（log-bin=xxx），且主从 server_id 必须不同。binlog 有三种格式：
- STATEMENT（SBR）：记录原始 SQL 语句；节省空间，但含 NOW()、UUID()、自增等非确定性函数时可能主从不一致；
- ROW（RBR）：记录每一行数据变更前后的完整镜像；安全可靠，日志体积大，尤其批量更新时；
- MIXED（MBR）：MySQL 自动判断，对非确定性语句降级为 ROW，其余用 STATEMENT；生产环境推荐此模式。
主库靠 Dump 线程推送变更
当从库发起连接后，主库会为每个从库单独创建一个 binlog dump 线程。该线程并不轮询，而是“监听”binlog 文件末尾——只要有新事件写入，就立即读取并推送给对应从库的 I/O 线程。它只负责传输，不参与事务控制或日志落盘确认。
注意：dump 线程与主库的客户端连接无关，即使主库当前无活跃会话，只要从库连着，dump 线程就持续待命。
从库靠 I/O 和 SQL 两个线程分工协作
从库启动复制（START SLAVE）后，会创建两个独立线程：
-
I/O 线程：连接主库 dump 线程，接收 binlog 内容，并原样写入本地 中继日志（relay log）；同时维护
master.info文件，记录已拉取到的 binlog 文件名与位置（File & Position）； - SQL 线程：单线程顺序读取 relay log，解析事件并执行（如重放 UPDATE），保证与主库变更顺序严格一致；它是串行回放的瓶颈点，也是延迟（Seconds_Behind_Master）的直接来源。
这种“拉取”与“执行”分离的设计，让 I/O 线程可以快速追赶主库进度，而 SQL 线程慢也不影响日志接收，提高了整体鲁棒性。
复制不是强一致，延迟与一致性需主动管理
默认异步复制下，主库提交事务后立即返回成功，不等待从库确认。这意味着：
- 主库宕机时，未传到从库的 binlog 会丢失；
- 从库 SQL 线程积压、大事务、锁竞争、磁盘 IO 慢都会导致 Seconds_Behind_Master 增长；
- 读从库可能读到旧数据（过期读），业务需明确接受最终一致性，或通过半同步、GTID、读写分离中间件等手段收敛风险。
不复杂但容易忽略。
