主从复制是通过从库重放主库binlog实现的最终一致性同步，依赖I/O线程拉取日志、SQL线程执行日志，存在延迟且不保证强一致性；配置需满足log-bin开启、server-id唯一非零、创建REPLICATION SLAVE权限用户三大前提，并推荐使用ROW格式确保数据一致。
主从复制就是让从库“重放”主库的变更操作
它不是实时镜像，也不是自动双向同步，而是主库把 INSERT、UPDATE、DELETE 这类写操作记进 binlog，从库靠两个线程——I/O Thread 拉日志、SQL Thread 执行日志——把同样的变更在自己身上再跑一遍。结果是：从库数据最终和主库一致，但中间必然有延迟，且无法保证强一致性。
配置时最常卡住的三个硬性前提
缺一不可，漏一个就 start slave 失败或线程直接挂掉：
-
log-bin必须在主库开启，否则没有日志可复制；从库可以不开启（除非它还要当其他库的主） -
server-id主从必须不同，且不能为 0 或重复——常见错误是两台都默认1，或者改完没重启 MySQL - 主库要创建专用复制用户，并授予
REPLICATION SLAVE权限，不能复用 root 或应用账号；密码里含特殊字符（如@、/）容易导致CHANGE MASTER TO解析失败
binlog_format 选 ROW 而不是默认 STATEMENT
MySQL 5.7+ 默认仍是 STATEMENT，但它在遇到 NOW()、UUID()、自增列冲突、非确定性函数时极易造成主从数据不一致。而 ROW 格式记录的是“哪一行被改了、改成什么样”，虽然日志体积大、网络带宽占用高，但数据一致性有保障，生产环境几乎无例外地应设为：
binlog_format = ROW
注意：ROW 模式下 SHOW BINLOG EVENTS 看不到 SQL，只能看到行变更事件，调试时需用 mysqlbinlog --base64-output=DECODE-ROWS -v 解析。
验证是否真同步成功，别只看 Slave_IO_Running: Yes
这两个值都为 Yes 只代表线程活着，不代表数据没丢、没延迟、没跳过错误：
- 查
Seconds_Behind_Master：大于 0 就说明落后，持续增长大概率是 SQL 线程卡在某条语句上 - 比对
Master_Log_File和Relay_Master_Log_File：如果不一致，说明 I/O 线程拉到了新日志，但 SQL 线程还没执行到对应位置 - 检查
Exec_Master_Log_Pos是否持续前进：长期不动，八成是复制中断，得查SHOW SLAVE STATUS\G里的Last_SQL_Error
真正可靠的验证方式，是在主库写入一条带唯一标识的测试记录（比如 INSERT INTO test_sync VALUES (NOW(), 'check-20260129');），然后立刻去从库查——等它出现，才算同步链路走通。
