ProxySQL通过配置同一hostgroup_id的多个从库实现读负载均衡，支持权重分配、健康检查与延迟感知，自动路由SELECT请求并剔除延迟超阈值的节点。
MySQL 通过多从库实现读负载均衡，核心在于把原本集中到主库的读请求，合理分发到多个从库上，既缓解主库压力，又提升整体查询吞吐能力。关键不在于堆机器，而在于“怎么分”和“分得稳”。
读请求必须路由到从库组，且多个从库之间要真正分摊流量
ProxySQL 是目前最常用、对新手最友好的实现方式。它作为中间代理层，接收所有客户端连接，再根据 SQL 类型和配置规则，把 SELECT 请求动态分配给不同从库。不是简单轮询，而是支持权重、健康检查、延迟感知等策略。
在
mysql_servers表中，把多个从库加入同一个hostgroup_id（比如 20），它们就自动构成一个可负载均衡的读节点池-
ProxySQL 默认对同一 hostgroup 内的服务器采用“最少连接数”策略；你也可以手动设置权重，例如：
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES (20, 'slave1', 3306, 3), (20, 'slave2', 3306, 2), (20, 'slave3', 3306, 1);
权重越高，被选中的概率越大，适合硬件配置不均的场景
所有以
SELECT开头的语句（不含FOR UPDATE）都会匹配规则，进入 hostgroup 20；ProxySQL 自动从中挑选一台健康的从库转发，无需应用层做任何修改
从库状态直接影响读负载是否真实均衡
光把从库加进组还不够。如果某台从库复制延迟严重（比如 lag > 5 秒），ProxySQL 仍可能把请求发过去，导致读到旧数据或超时。因此必须开启监控与自动剔除：
- 启用
monitor模块，定期执行SELECT @@gtid_executed或SHOW SLAVE STATUS检查复制延迟和 IO/SQL 线程状态 - 配置
mysql_replication_hostgroups表，让 ProxySQL 自动识别并隔离延迟超标或同步中断的从库 - 延迟阈值建议设为 1–3 秒（业务容忍范围内），超过即临时下线，恢复后自动重新加入
写操作和强一致性读不能走从库，否则会出错
不是所有 SELECT 都能随便分发。以下两类必须回到主库：
- 显式加锁的查询：
SELECT ... FOR UPDATE、SELECT ... LOCK IN SHARE MODE—— 这类属于事务内写前读，必须与后续UPDATE在同一节点，否则会锁不一致或死锁 - 刚写入就立刻读的场景（如注册后立即查用户信息）：应用可通过 Hint（如
/*+ USE_MASTER */）或连接特定端口（如主库专用 3307）绕过读负载均衡，直连主库
从库数量不是越多越好，需匹配实际读压力与维护成本
3 台从库在多数中型业务中已足够支撑 5–8 倍读 QPS 提升；盲目增加到 5 台以上，反而带来：
- 主从复制链路变长，延迟风险上升
- ProxySQL 路由决策开销微增（但可忽略）
- 运维复杂度明显提高（备份、升级、监控项翻倍）
建议按「单从库承载 1500–3000 QPS」估算，再预留 30% 余量，反推所需从库数量。
本质上，多从库读负载均衡是“复制 + 路由 + 监控”三者闭环的结果。只要主从同步稳定、ProxySQL 规则清晰、延迟监控有效，就能让读流量真正跑起来，而不是只停留在配置里。
