mysql主从复制如何实现负载均衡_mysql读写分离实战

mysql主从复制非负载均衡方案，需依赖中间件或应用层实现读写分离；从库延迟和主库单点是核心风险，须监控延迟并评估分库分表。

MySQL 主从复制本身不提供负载均衡

主从复制只是数据同步机制，不是负载均衡方案。它把主库的写操作通过 binlog 重放同步到从库，但客户端连接、SQL 路由、故障转移这些都得靠上层组件完成。直接连多个从库并轮询发 select，属于“伪负载均衡”，没健康检查、无自动剔除、不感知延迟，线上基本不可用。

读写分离必须依赖中间件或应用层路由

常见可行路径只有两条：

• 应用层控制：在代码里显式指定 readDataSource 和 writeDataSource，用 AOP 或注解（如 @ReadOnly）切分数据源。适合 spring Boot 项目，可控性强，但侵入业务逻辑，且容易漏写或误标
• 代理层分流：用 ProxySQL、MaxScale 或 ShardingSphere-Proxy。它们解析 SQL 类型，自动把 INSERT/UPDATE/delete 转给主库，SELECT 分发到从库池。注意：SELECT 不一定都走从库——带 for UPDATE、在事务中、或查询涉及未同步完的表时，代理通常会 fallback 到主库

从库延迟和一致性是最大陷阱

即使配置了半同步复制（rpl_semi_sync_master_enabled=ON），网络抖动、大事务、从库 IO 压力仍会导致秒级甚至分钟级延迟。后果很直接：

• 用户刚提交订单，立刻查列表却看不到新记录（从库还没同步完）
• 缓存穿透后回源查库，查到的是旧数据，再写进缓存，污染整个缓存层
• ProxySQL 的 mysql_servers 表里虽然有 status 字段，但默认不监控复制延迟；需手动配置 monitor_username 并启用 mysql-monitor_replication_lag_max 参数，否则延迟从库照常接流量

不要忽略主库单点和写瓶颈

读写分离只缓解读压力，主库仍是单点。如果写入 QPS 上万，或者存在大量 ALTER table、LOAD DATA 操作，主库 CPU/IO/锁竞争会迅速成为瓶颈。此时光靠加从库没用，得考虑：

• 拆分写逻辑：比如日志类写入走 kafka + 异步落库，降低主库实时写压
• 升级硬件或换存储引擎（InnoDB 对高并发写比 MyISAM 更稳）
• 评估是否该上分库分表（ShardingSphere 或 vitess），而不是继续堆主从

真正上线前，务必用 pt-heartbeat 持续观测从库延迟，同时在 ProxySQL 中打开 stats_history 查看实际路由分布——很多团队配完才发现 90% 的 SELECT 还是打到了主库，因为没关掉应用里的默认数据源配置。