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