17370845950

读写分离是将读写操作分发至主从库，主库处理写和强一致性读，从库承担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 STATUS\G检查Seconds_Behind_Master是否稳定为0或小幅波动。

• 推荐使用GTID模式，避免手动找位点出错
• 主从网络需低延迟高可靠，跨机房部署要谨慎评估延迟影响
• 定期校验主从数据一致性（如pt-table-checksum工具）

应用层路由策略设计

读写分离不能只靠数据库中间件，应用逻辑也要配合。常见做法是在DAO或ORM层识别SQL类型：显式写操作走主库连接；普通查询默认走从库；但涉及刚写入就查的场景（如注册后立即显示用户信息），必须强制走主库，否则可能查不到或查到旧数据。

• 可借助注解（如@Master/@Slave）或方法命名约定控制路由
• 事务内所有SQL默认走主库，避免从库读到未提交变更引发混乱
• 监控慢查询分布，确认读请求确实落到从库，防止“读写都在主库”白搭

高可用与故障应对机制

主库宕机时，需快速切换新主库并重置从库复制关系。单纯依赖MHA或Orchestrator等工具还不够，应用侧也得支持动态更新数据源地址。同时，从库异常下线时，负载应自动剔除该节点，避免查询失败；若多数从库延迟飙升，可临时将部分读流量切回主库（降级策略），保障可用性优先于分离目标。

• 主库切换后，原主库恢复需作为从库重新接入，不可直接启用
• 从库只读模式务必开启（set global read_only=ON），防误写污染
• 连接池配置要区分主库（强一致性要求）和从库（容忍短时延迟）的超时与重试策略