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 还是打到了主库，因为没关掉应用里的默认数据源配置。
