MySQL 主从复制原理是什么？主从延迟从哪来、怎么治理？
结论先行：主从复制本质是“主库把 binlog 传给从库并重放”。主库写 binlog 后由 dump 线程推送给从库，从库 IO 线程收下写入 relay log，SQL 线程再重放。延迟主要来自 SQL 线程重放跟不上主库写入，常见诱因是大事务、单线程重放、从库自身有查询压力。
一、复制链路三线程
| 线程 | 位置 | 职责 |
|---|
| dump 线程 | 主库 | 读 binlog 推送给从库 |
| IO 线程 | 从库 | 收 binlog 写入 relay log |
| SQL 线程 | 从库 | 读 relay log 在从库重放 |
主库 binlog --(dump)--> 从库 relay log --(SQL 线程)--> 从库数据
二、同步模式对比
| 模式 | 主库提交是否需要从库确认 | 数据风险 | 性能 |
|---|
| 异步 | 不需要 | 主库宕机可能丢 binlog | 最好 |
| 半同步 | 至少一个从库确认收到 | 基本不丢 | 略降 |
| 组复制 | 多数派确认 | 不丢，多写受限 | 最低 |
三、延迟为什么产生
- 大事务：一次改百万行，重放耗时远大于生成耗时。
- 单线程重放：默认一个 SQL 线程，写入并行的主库很快就甩开从库。
- 从库压力：从库还承担读流量或备份，与重放抢 CPU/IO。
- 其它：DDL 长时间持锁、主从硬件差异、网络抖动影响 IO 线程。
四、治理手段
- 开启并行复制：slave_parallel_workers > 1，按库/按事务粒度并行重放。
- 拆分大事务：批量 UPDATE/DELETE，控制单事务影响行数。
- 从库专职：读流量分散到多个从库，备份避开高峰。
- 监控告警：盯 Seconds_Behind_Master 与两个线程状态。
SHOW SLAVE STATUS\G
-- 关注：Slave_IO_Running / Slave_SQL_Running / Seconds_Behind_Master
常见追问与记忆点
- 追问：Seconds_Behind_Master 可信吗？它是估算值，时钟偏差或长事务下会失真，要配合 binlog 位点判断。
- 追问：主库宕机后从库怎么接管？选延迟最小、数据最全的从库提升为主库，应用切换连接。
- 记忆点：一主推 binlog，两线程接力重放；延迟 = 重放跟不上写入，靠并行复制 + 拆大事务 + 监控。