数据库代理的负载均衡策略并不只是把请求平均分给后端，它实际上在决定哪些 SQL 走主库、哪些 SQL 走从库；策略配置一旦偏向简单轮询，读写分布就会失控，主从延迟和锁等待会直接放大。
数据库代理负载均衡策略为什么能改写读写分布
数据库代理坐在应用和数据库实例中间,每一条 SQL 都要先经过它，代理收到请求后，会根据配置的负载均衡策略选择一个后端节点转发，这里的关键是：策略不是随机选择，它决定了读请求是否会被塞给主库，写请求是否会被误发到从库。
- 如果代理用纯轮询,读写请求会均匀落到所有节点，包括从库。
- 如果代理用基于 SQL 解析的规则，
SELECT走读节点，INSERT、UPDATE、DELETE走主节点。 - 如果代理只做连接级分发,不识别 SQL 类型，读写分布就完全依赖应用入口是否拆分。
所以同一个数据库集群,换一套代理策略，主库的 CPU、连接数、锁等待都会发生明显变化，读多写少的业务里，主库本该只承接少量写入，但策略不当会让主库继续扛着大量读流量，只读实例反而闲置。
数据库代理负载均衡策略对比：谁适合读多写少场景
不同策略对读写分布的影响差别很大,下面这张表把常见策略放在一起看，能快速判断哪种更适合生产环境。
| 策略 | 读写分布效果 | 适用场景 | 主要风险 |
|---|---|---|---|
| 轮询 | 读写平均分散 | 测试环境、一致性要求低 | 写请求可能打从库 |
| 加权轮询 | 可按权重提高读节点接收量 | 读多写少且实例性能不一致 | 权重配置不当会倾斜 |
| 最少连接 | 动态按当前连接数分配 | 长连接较多 | 无法区分读写类型 |
| 源 IP 哈希 | 同一应用服务器固定走同一节点 | 有会话保持需求 | 分布可能不均匀 |
| 基于 SQL 解析的读写分离 | 读走从库、写走主库 | 生产环境读多写少 | 规则维护成本略高 |
读多写少推荐最少连接加读写规则
多数互联网业务的读请求远多于写请求,单独用最少连接，虽然能缓解连接压力，但没法保证写请求不进从库，更稳妥的做法是把最少连接作为节点选择基础，再叠加一层 SQL 解析规则：只有明确的读语句才允许进入只读节点，其他语句强制回主库。
强一致场景不要用纯轮询
订单、库存、账户余额这类业务，读操作也不能随便走从库，从库有复制延迟，纯轮询会让刚提交的写操作立刻被读出来，结果表现为“支付成功了页面还显示未支付”，这种情况下，代理需要支持事务粘滞，同一个事务内的语句全部走主库，而不是按轮询策略继续分散。
生产环境数据库读写分离方案如何落地
生产环境落地读写分离,不只是在代理上开两个端口，要按“入口拆分、规则落地、健康检查、延迟摘除”四步走。
- 应用使用两个连接地址：一个读写入口，一个只读入口。
- 代理对读写入口分别绑定主节点和只读节点。
- 在代理层配置 SQL 规则，防止写语句从只读入口混进来。
- 对只读节点做复制延迟检测,延迟超过阈值的实例自动摘除。
数据库读写分离代理怎么配置才不踩坑
以 ProxySQL 这类支持 SQL 层路由的代理为例，核心配置不是改应用代码，而是让代理识别语句模式。
- 建立两个主机组：
hostgroup 1放主库，hostgroup 2放从库。 - 配置查询规则,把
^SELECT开头且不含FOR UPDATE的语句路由到hostgroup 2。 - 把其他语句默认路由到
hostgroup 1
。
- 把规则加载到运行态并保存。
配置语句大致如下：
INSERT INTO mysql_query_rules (rule_id,active,match_pattern,destination_hostgroup,apply)
VALUES (1,1,'^SELECT',2,1);
UPDATE mysql_query_rules SET destination_hostgroup=1 WHERE match_pattern='.';
LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;验证时可以在代理入口执行：
SELECT @@hostname;如果返回的是从库主机名,说明读规则已经生效，再执行一条 BEGIN 开启事务，然后执行 SELECT @@hostname，正确结果应该回到主库，因为事务内语句必须保持主库一致性。
从库延迟如何影响负载均衡策略
从库复制慢的时候,代理还继续把读请求分过去，就会出现业务读到旧版本数据，多数代理支持给从库设置最大延迟阈值，比如从库的 Seconds_Behind_Master 超过设定值，代理就暂时把这个节点标记为不可用，直到延迟恢复。
配置路径通常类似：
UPDATE mysql_servers SET max_replication_lag = 3 WHERE hostgroup_id = 2;这个数值不是拍脑袋定的,订单查询类业务可以放宽到几秒，库存展示类业务要更严格，行业共识认为，读写分离不是简单地把读请求甩给从库，而是要和延迟监控联动，否则从库越多，数据不一致的窗口反而越难排查。
数据库代理价格一般多少与北京地域选择
数据库代理价格一般多少,这个问题没有统一答案，云上代理通常按代理实例规格和使用时长计费，规格越高、连接数越大，价格越高，私有化部署的代理软件可能按节点数或年付授权收费，价格差异来自协议兼容性、SQL 解析能力、是否带监控面板等因素。
选型时不要先看价格,先看业务需要多大的连接并发，如果只用轮询做转发，轻量代理就够；如果要精准读写分离，代理需要支持 SQL 解析和延迟检测，这部分成本会高一些。
北京数据库代理服务商怎么选
北京地域的数据库代理选型,优先考虑同机房或同可用区部署，跨地域转发会让每一条 SQL 多出几毫秒到几十毫秒的网络延迟，读写分布越精确，代理层多出来的延迟反而越明显。
- 看服务商是否在北京有节点,能否走内网访问数据库。
- 看代理是否支持 MySQL、PostgreSQL 等目标协议版本。
- 看是否支持只读实例自动发现,避免新增从库后还要手动更新代理配置。
- 看配置方式是否开放 API，能不能和运维平台对接。
负载均衡策略不是独立开关，它和读写分离规则、从库延迟检测、事务边界共同决定数据库读写分布，策略选错，再加只读实例也压不住主库；策略配置到位，主库才能真正从读流量中解放出来。
数据库代理负载均衡策略常见问题
数据库代理负载均衡策略如何影响读写分布？
代理在 SQL 入口处做决策，如果策略只按连接数或轮询分发，读和写会混合落到主库、从库，如果策略能解析 SQL 类型，SELECT 会被导向只读节点，写入语句留在主库，代理的规则优先级越清晰，读写分布就越符合业务预期，主库负载下降越明显。
生产环境数据库读写分离方案用 ProxySQL 还是 MySQL Router？
两者都可用于生产环境,ProxySQL 擅长 SQL 层规则和延迟管理，适合需要精细化控制读写分布的 MySQL 集群，MySQL Router 更轻量，适合与云上托管数据库搭配，配置简单但 SQL 层控制能力弱一些，选择取决于团队是否愿意维护规则表，以及从库数量是否频繁变化。
数据库代理价格一般多少才合理？
合理价格不取决于代理本身报价,而取决于读节点数量和业务峰值连接数，按这两个指标去匹配服务商规格表，能避开为用不上的连接数付费，云上代理按小时计费的产品，可以在业务低峰期缩容，进一步摊薄数据库代理价格一般多少带来的成本压力。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637787.html
