MySQL读写分离需合理分发读写请求并应对主从延迟，适用报表等弱一致性场景，强一致读必须走主库；实现方式有应用层路由、中间件代理和驱动层；须监控延迟、提供强制主库读、优化复制机制；从库还可用于备份、分析和异地读。
MySQL 读写分离不是简单加个代理或配个从库就能生效的，核心在于把读请求合理分发到从库、写请求严格落在主库，并规避主从延迟带来的数据不一致问题。架构设计要兼顾可用性、一致性、可维护性和业务适配性。
明确读写分离的适用边界
并非所有读场景都适合走从库：
- 强一致性读（如用户刚下单立刻查订单状态）必须走主库，否则可能查不到最新数据
- 报表类、后台管理类、对实时性不敏感的查询，是读写分离的主要受益场景
- 高频小查询（如配置表、字典表）可考虑缓存兜底，比走从库更轻量
- 跨库事务、复杂 join 涉及主从不同步风险，需评估是否拆分或改用其他方案
选择合适的分流方式
常见有三类实现路径，选型取决于团队技术栈和运维能力：
- 应用层路由：在代码中显式指定数据源（如 MyBatis 的 AbstractRoutingDataSource），灵活可控，但侵入业务逻辑，需统一封装避免散落
- 中间件代理：用 ShardingSphere-Proxy、MaxScale、ProxySQL 等，对应用透明，支持 SQL 解析与自动路由，但引入新组件，需关注其稳定性与主从延迟感知能力
- 数据库驱动层：如 MySQL Connector/J 的 loadBalance 连接串（配合 replication-aware 配置），轻量但功能有限，不支持复杂策略
必须应对主从延迟问题
延迟是读写分离的“天敌”，不能靠“尽量减少”来解决，而要主动防御：
- 监控并告警复制延迟（Seconds_Behind_Master 或 GTID 方式更准），延迟超阈值时可临时将该从库摘除
- 对关键读操作提供“强制主库读”开关（如注解 @Master 或请求头 x-force-master），业务按需触发
- 利用 semi-sync 复制 + 并行复制（MTS）降低延迟基线，但不能完全消除
- 部分场景可结合 binlog 位点或 GTID 等待机制，在从库上等待指定变更同步完成后再执行读，代价是增加响应时间
从库不止用于读，还要承担其他职责
合理复用从库资源能提升整体性价比：
- 备份任务统一从某台专用从库拉取，避免影响线上读性能
- 慢查询分析、SQL 审计、全量日志采集等后台任务也应隔离到非核心从库
- 可部署只读实例做数据分析或 BI 查询，与业务读流量物理隔离
- 多地域部署时，异地从库可服务本地读请求，降低网络延迟，但需权衡跨地域复制稳定性
