MySQL主从复制通过将读请求路由至只读从库、写请求保留在主库，实现读压力分担；需解决主从延迟、从库故障剔除、负载均衡及事务一致性等问题，并可结合并行复制、规格差异化配置与读缓存优化。
MySQL 主从复制本身不直接分担写压力，但能有效分担读压力——只要把读请求路由到从库，写请求保留在主库，就能显著提升整体读并发能力。
主从架构如何分担读压力
主库负责所有 INSERT/UPDATE/DELETE 操作，数据通过 binlog + 复制线程实时同步到一个或多个从库；从库开启只读（red">read_only=ON），专用于处理 SELECT 请求。这样读操作被分散到多台机器，单点查询瓶颈消失，QPS 可线性扩展（受限于从库数量和网络延迟）。
读写分离的实现方式
- 应用层路由：在代码中显式指定读库或写库（如 MyBatis 的 AbstractRoutingDataSource、ShardingSphere-JDBC 的 Hint 或注解）。适合可控性强、逻辑清晰的场景。
- 中间件代理：用 ProxySQL、MaxScale 或 ShardingSphere-Proxy 自动识别 SQL 类型，将 SELECT 转发至从库，DML 转发至主库。对业务无侵入，但增加部署和运维复杂度。
- 数据库连接池支持：如 HikariCP 配合自定义负载策略，或 Druid 内置的 read-write-splitting 扩展。需注意事务内强制走主库的兜底逻辑。
必须处理的关键问题
- 主从延迟导致读到旧数据：监控 Seconds_Behind_Master，对一致性要求高的查询（如订单支付后查结果）应强制走主库，或加延时等待逻辑。
- 从库故障自动剔除：中间件或客户端需具备健康检查与动态下线能力，避免请求打到不可用从库上。
- 读库负载不均：按从库性能（CPU、IO、延迟）加权分配读流量，而非简单轮询；可结合心跳响应时间做实时权重调整。
- 事务内读写一致性：开启事务后的所有读操作必须落在同一节点（通常是主库），否则可能违反事务隔离性，尤其在 REPEATABLE READ 下易出问题。
进阶优化建议
- 从库可配置不同规格：热点查询多的业务用高配从库，报表类用低配+延迟同步，降低成本。
- 开启并行复制（slave_parallel_workers > 0）减少延迟，尤其在多库多表写入场景下效果明显。
- 从库关闭 query cache、禁用 binlog（log_bin=OFF）、调大 innodb_buffer_pool_size，专注读性能。
- 配合读缓存（如 Redis）进一步降低从库压力，但要注意缓存与数据库的一致性策略。
