主从复制复制的是主库binlog中记录的INSERT、UPDATE等数据变更事件；需开启log-bin、配置唯一server-id，采用ROW格式；依赖Binlog Dump、IO和sql三个线程协作，SQL线程串行回放易致延迟；初始化需同步历史数据，否则从库为空。
主从复制就是让一台 mysql（主库）把数据变更自动同步给另一台或几台 MySQL（从库），实现数据实时备份和读写分离的基础机制。
主从复制到底在复制什么？
它复制的不是整张表或整个库的快照，而是主库上执行过的「数据变更事件」——比如 INSERT、UPDATE、delete、CREATE table 这类操作，被记录在主库的 binlog（二进制日志）里。从库不直接读主库磁盘，而是通过网络拉取这些日志，再在本地重放一遍。
- 主库必须开启
log-bin，否则没日志可复制 - 主从必须配置不同的
server-id，否则从库拒绝连接 - 复制默认是异步的：主库写完
binlog就返回成功，不等从库落盘——这意味着主库宕机时，最后几秒的数据可能丢失 -
binlog_format推荐设为row：基于行的复制更可靠，避免函数、时间戳、自增 ID 等非确定性语句导致主从不一致
三个关键线程是怎么协作的？
主从同步靠三个核心线程驱动，缺一不可：
- 主库的
Binlog Dump Thread：每个从库连上来，主库就启一个这个线程，负责把binlog内容推过去 - 从库的
IO Thread：连接主库，接收binlog并写入本地的relay-log（中继日志），同时更新master.info记录已同步到的位置 - 从库的
SQL Thread：读relay-log，解析成 SQL 并执行——注意：它是单线程串行回放的，这是主从延迟最常见的根源
你可以用 SHOW PROCEsslIST 在主从两端分别看这三个线程是否活跃；用 SHOW SLAVE STATUSG 查看 Seconds_Behind_Master 判断延迟程度。
为什么刚配好主从，从库数据还是空的？
因为复制只同步「配置完成后发生的变更」，不会自动搬运历史数据。常见错误是跳过这一步，直接 CHANGE MASTER TO，结果从库永远追不上。
- 若主库是新实例、无业务数据，可跳过初始化，直接记下
SHOW MASTER STATUS的File和position - 若主库已有数据，必须先锁表（
FLUSH TABLES WITH READ LOCK）、导出（mysqldump或物理拷贝）、恢复到从库，再解锁、再配置复制起点 - 跳过初始化又没锁表，会导致主从数据逻辑错位——比如从库少了几万条用户注册记录，但后续订单却正常同步，查起来毫无头绪
真正难的不是配通，而是配稳：延迟突增、SQL Thread 报错中断、relay-log 损坏、GTID 开关不一致……这些往往在流量高峰或大事务后才暴露。别只盯着 Slave_IO_Running: Yes 和 Slave_SQL_Running: Yes，得定期查 Seconds_Behind_Master 趋势和 SHOW SLAVE STATUS 里的 Exec_Master_Log_Pos 是否持续前进。