主从复制就是让一台 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 STATUS\G查看
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是否持续前进。
