第 14 篇 主从复制与读写分离：binlog 格式、主从延迟的成因与应对

开篇钩子

主从复制是 MySQL 高可用的基石，但它从来不是"零延迟"的魔法。一个高并发写入的主库，从库可能永远追不上；一个长事务的 binlog，从库回放时会把整个并行度退化成单线程。搞清楚复制的机制，才能真正用好读写分离，也才能在出现延迟时不慌不忙地找到根因。

1. 主从复制的工作原理

MySQL 复制的核心是binlog（binary log）——主库的所有变更都会写入 binlog，从库把这些日志拉过来回放，从而保持数据一致。

三个线程，两个文件

主库: ┌──────────────────────────────────────────────────┐ │ 写线程 → binlog（数据变更日志，按 event 组织） │ │ Dump Thread → 接受从库连接，推送 binlog │ └──────────────────────────────────────────────────┘ ↓↓↓ TCP 从库: ┌──────────────────────────────────────────────────┐ │ I/O Thread → 连接主库，接收 binlog，写到 Relay Log │ │ SQL Thread → 读取 Relay Log，回放事件（执行 SQL） │ └─────────────────────────────────────────