MySQL读写分离需借助代理层（如ProxySQL）、中间件（如ShardingSphere）或应用层（如Spring路由）实现，核心是分摊主库压力，但须应对主从延迟、一致性及运维复杂度问题。
MySQL 读写分离本身不内置实现，需借助中间件、代理或应用层逻辑将读请求路由到从库、写请求发往主库。核心目标是分摊主库压力、提升并发读能力，但不当配置反而会引入延迟、一致性问题和运维复杂度。
一、常见读写分离实现方式
根据架构层级不同，主流方案有三类：
- 代理层方案：如 MySQL Router（官方）、ProxySQL（功能强、支持动态权重与故障自动切换）、MaxScale。它们位于应用和数据库之间，解析 SQL 类型自动路由，对应用透明。
- 中间件方案：如 ShardingSphere-Proxy、MyCat（已趋于维护状态）。适合复杂分库分表+读写分离混合场景，但学习成本高、协议兼容性需验证。
- 应用层控制：在代码中显式指定数据源（如 Spring 的 AbstractRoutingDataSource），用注解或 ThreadLocal 标记读/写操作。灵活性高、无额外组件依赖，但需团队统一规范，易误用。
二、避免“读从库却查不到最新数据”
主从复制存在天然延迟（秒级甚至更高），直接读从库可能导致刚写入的数据查不到（即过期读）。关键应对策略：
- 对强一致性要求的读操作（如订单创建后立即查详情、支付结果回调），强制走主库；可通过注解（如
@Master）或上下文标记实现。 - 开启并合理使用 semi-sync replication（半同步复制），确保至少一个从库落盘才返回写成功，降低延迟上限（但会轻微增加写响应时间）。
- 监控 Seconds_Behind_Master，当延迟超阈值（如 > 5s）时，临时将该从库摘除或降权，防止流量打到严重滞后的节点。
三、性能优化关键点
读写分离不是“一配了之”，以下细节直接影响效果：
- 从库规格不低配：从库 CPU、IO、内存不应明显弱于主库，否则复制线程持续积压，延迟恶化；建议同规格或仅网络略低。
-
关闭从库写操作与非必要日志：设置
read_only=ON，禁用innodb_flush_log_at_trx_commit=2和sync_binlog=0（仅限从库），减少刷盘开销。 - 合理分配读负载：用 ProxySQL 或 ShardingSphere 配置从库权重，按机器性能差异化分配；避免所有读请求集中到单个从库。
- 索引与查询优化仍不可少：读写分离不能掩盖慢查询。从库上同样要保障高频查询有合适索引，避免全表扫描拖垮复制线程。
四、必须做的基础保障
脱离运维保障的读写分离很脆弱：
- 部署 MHA 或 pt-table-checksum），发现不一致及时修复，防止“越跑越偏”。
- 所有从库开启 relay_log_recovery=ON，崩溃重启后自动恢复中继日志，避免复制中断。
