主从复制是读写分离的前提但不等于读写分离；主库必须启用binlog且server-id唯一，配置错误会导致复制失败；从库需严格对齐主库binlog文件与位置，推荐GTID或mysqldump+--master-data=2；验证时须关注Seconds_Behind_Master和Exec_Master_Log_Pos；读写分离应由ProxySQL等中间件实现，避免DNS/LB轮询；从库应设read_only=ON并确保时间、字符集一致。
主从复制本身不等于读写分离，它只是读写分离的前提；直接在应用里硬编码路由逻辑或依赖中间件时，配置错一个参数就可能导致写请求打到从库、脏读或复制中断。
主库必须启用 binlog 且 server-id 唯一
这是复制链路的起点，缺一不可。常见错误是只改了 server-id 却漏开 log-bin，或者多个实例用了相同 server-id（比如都设成 1）导致从库无法识别主库身份。
-
log-bin必须在[mysqld]下显式声明，例如log-bin=mysql-bin；路径默认在 datadir 下，不建议用绝对路径 -
server-id推荐用 IP 末段（如 192.168.88.53 →server-id=53），避免手动冲突 - MySQL 8.0+ 默认
binlog_format=ROW，无需额外设置；若需兼容旧应用，可显式加binlog_format=MIXED - 重启前检查配置语法：
mysqld --defaults-file=/etc/my.cnf --validate-config，避免启动失败
从库执行 change master to 时必须对齐主库的 binlog 文件和位置
这个步骤最容易出错——show master status 的输出必须在主库锁表（flush tables with read lock）后立即获取，否则从库可能跳过部分事务，造成数据不一致。
- 主库执行
flush tables with read lock后，立刻运行show master status，记下File和Position - 从库的
change master to中，master_log_file和master_log_pos必须严格匹配上一步结果，大小写、数字、点号都不能错 - 如果主库已运行一段时间，更稳妥的做法是先 mysqldump 全量导出 +
--master-data=2，再导入从库，这样位置信息自动嵌入 - MySQL 8.0.23+ 支持
CHANGE MASTER TO ... SOURCE_AUTO_POSITION = 1（基于 GTID），可跳过手动指定位置，但要求主从都开启gtid_mode=ON
验证复制状态不能只看 Slave_IO_Running 和 Slave_SQL_Running
两个线程显示 Yes 只说明复制进程在跑，不代表数据实时同步。真正要盯的是 Seconds_Behind_Master 和 Exec_Master_Log_Pos 是否持续增长。
- 执行
show slave status \G后，重点检查：Seconds_Behind_Master: 0、Slave_SQL_Running_State: Slave has read all relay log - 如果
Seconds_Behind_Master持续增大，优先查网络延迟、从库磁盘 I/O、大事务（如单条UPDATE影响百万行）或relay_log_space_limit是否耗尽 - 避免在从库执行
set global sql_log_bin=0，这会导致 DML 不写 binlog，后续切换主库时可能丢失这部分变更 - 从库应设为只读：
read_only=ON（非 super 用户无法写），但注意 super 用户仍可写，生产环境建议配合super_read_only=ON（MySQL 5.7.8+）
读写分离必须由中间件或应用层控制，不能靠 DNS 或负载均衡轮询
DNS 解析或四层 LB（如 LVS）无法识别 SQL 类型，把 SELECT 请求随机分发到主库或从库，会破坏一致性；而代码里手动判断语句类型又容易漏判或误判。
- 推荐用
ProxySQL或MaxScale：它们能解析 SQL 语法，按规则路由（如^SELECT→ 从库组，^INSERT|^UPDATE→ 主库组） - 若用应用层方案（如 Spring 的
AbstractRoutingDataSource），必须确保事务内所有读操作都走主库（@Transactional下的SELECT不能去从库） - 严禁在从库执行
SELECT FOR UPDATE，这会触发锁等待甚至死锁，因从库的行锁机制与主库不同步 - 监控项不能只看连接数，要抓取
mysql_servers表中各节点的status和weight，防止某台从库宕机后流量仍被分配过去
最常被忽略的是时间同步和字符集一致性：主从服务器系统时间差超过 1 秒，会导致基于时间戳的 binlog 解析异常；主库用 utf8mb4_unicode_ci 而从库用 utf8mb4_general_ci，某些排序或比较行为会不一致，最终引发复制中断。
