读写分离是将读写操作分发至主从库，主库处理写和强一致性读，从库承担 SELECT 查询，需接受主从延迟；需正确配置 MySQL 主从复制（推荐 GTID）、应用层路由控制、高可用切换及从库只读保护。
读写分离的核心原理
读写分离本质是把数据库的读操作和写操作分发到不同实例上。主库负责所有写入（INSERT/UPDATE/DELETE）和强一致性读，从库只承担 SELECT 查询。这样能缓解单库压力，提升整体吞吐量。关键前提是业务能接受主从延迟——因为从库数据是异步或半同步复制来的，通常有几十毫秒到几秒不等的延迟。
MySQL 主从搭建与复制配置
先确保主从基础环境一致（版本建议相同或从库不低于主库）。在主库开启 binlog，设置唯一 server-id；从库配置对应 server-id，并用 CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）或CHANGE MASTER TO（旧版本）指向主库 IP、 端口 、binlog 文件和位置。启动复制后，用SHOW REPLICA STATUSG 检查 Seconds_Behind_Master 是否稳定为 0 或小幅波动。
- 推荐使用 GTID 模式，避免手动找位点出错
- 主从网络需低延迟高可靠，跨机房部署要谨慎评估延迟影响
- 定期校验主从数据一致性（如 pt-table-checksum工具）
应用层 路由 策略设计
读写分离不能只靠数据库中间件，应用逻辑也要配合。常见做法是在 DAO 或 ORM 层识别 SQL 类型：显式写操作走主库连接；普通查询默认走从库；但涉及刚写入就查的场景（如注册后立即显示用户信息），必须强制走主库，否则可能查不到或查到旧数据。
- 可借助注解（如 @Master/@Slave）或方法命名约定控制路由
- 事务内所有 SQL 默认走主库，避免从库读到未提交变更引发混乱
- 监控慢查询分布，确认读请求确实落到从库，防止“读写都在主库”白搭
高可用与故障应对机制
主库宕机时，需快速切换新主库并重置从库复制关系。单纯依赖 MHA 或 Orchestrator 等工具还不够，应用侧也得支持动态更新数据源地址。同时，从库异常下线时，负载应自动剔除该节点，避免查询失败；若多数从库延迟飙升，可临时将部分读流量切回主库（降级策略），保障可用性优先于分离目标。
- 主库切换后，原主库恢复需作为从库重新接入，不可直接启用
- 从库只读模式务必开启（set global read_only=ON），防误写污染
- 连接池配置要区分主库（强一致性要求）和从库（容忍短时延迟）的超时与重试策略
