数据库代理的负载均衡策略直接决定SQL请求被分发到哪个实例，选错策略会让读写分布失衡，主库压力飙升，从库延迟追不上，业务端读到的数据滞后。
数据库代理负载均衡算法对比：轮询与最小连接数怎么选
数据库代理就像一个中转门卫,站在业务和后端实例中间，负责把SQL请求送进正确的门，这个“送”的过程，就是负载均衡的核心，你问轮询和最小连接数怎么选，其实要看你的业务请求长什么样。
轮询算法适合什么样的架构
轮询是最朴素的策略,按顺序把新请求轮流发给各个实例，雨露均沾，这种算法最适合规格完全一致、请求耗时差不多的实例组，比如你买了一排同配置的只读从库，查询都是简单的索引命中，轮询就能把流量分得很均匀。
但主从架构里,轮询有个明显的坑，它不区分主库还是从库，如果主库也参与轮询，写请求和读请求混在一起，主库很快会被读流量淹没，多数生产环境会先把主库踢出轮询组，只让轮询在从库之间转。
最小连接数适合长连接和慢查询混合的场景
最小连接数算法会把新请求交给当前活跃连接最少的实例,长连接多、请求耗时差异大的场景，这是更聪明的选择，比如业务里有不少报表查询，一次要跑好几秒，这类请求占了连接不释放，轮询照样往下发，慢实例就会越积越多，最小连接数会主动避开繁忙实例，把请求送到闲置的一侧。
配置最小连接数时,连接池的超时参数要同步调整，代理统计的是后端连接数，不统计应用侧等待队列的长度，如果超时时间设得太长，照样会出现局部过热。
加权轮询和一致性哈希的适用场景
加了权重的轮询,适合实例规格不统一的集群，比如你用了三台旧机器跑从库，其中一台内存翻倍，可以把权重从1调到2，让大内存实例分担更多读流量，权重设置不是拍脑袋，建议先跑一段时间的监控，看CPU和IO吞吐的实际水位，再反推权重比例。
一致性哈希则是按某个key（比如用户ID、订单号）做哈希取模，让同一个key的请求总落在同一实例上，这对带本地缓存的从库特别有用，缓存命中率上去了，后端压力自然降下来。
| 策略 | 核心逻辑 | 推荐场景 | 注意事项 |
|---|---|---|---|
| 轮询 | 按顺序分发 | 同配置实例、短查询为主 | 需排除主库 |
| 最小连接数 | 给最空闲的实例 | 长连接多、耗时差异大 | 关注超时参数 |
| 加权轮询 | 按权重比例分发 | 实例规格不一致 | 权重需监控校准 |
| 一致性哈希 | 相同key相同实例 | 本地缓存、会话保持 | 扩容时命中率下降 |
智能路由：代理如何识别读写语句
代理不只是按策略转发,还要会看SQL的“脸色”，正则匹配或者SQL解析器会识别语句类型，SELECT走从库，INSERT/UPDATE/DELETE走主库，很多代理还支持按表名、按用户做更细粒度的路由，比如SELECT ... FOR UPDATE这类带锁的读，必须走主库，代理得能识别出来。
但这中间有个常见的坑：事务内的读请求，一个事务里先UPDATE再SELECT，如果SELECT被路由到从库，大概率读到旧数据，行业共识认为，事务内的全部语句都应当路由到主库，直到事务提交，这需要代理能感知事务的开始与结束，不只是看单条语句的类型。
数据库读写分离延迟问题的排查思路
读写分离的延迟,是代理负载均衡策略最容易“背锅”的问题，当从库落后主库有较大时间差，代理却把读请求持续分发到落后的从库，业务侧就会看到刚写的数据查不到或报错。
复制延迟链条的常见瓶颈
从库同步有完整链路：主库提交事务→写binlog→从库拉取日志→写入relay log→SQL线程回放，业内专家指出，延迟的拐点多数不在网络，而在SQL线程的回放速度，主库是大并发写入，从库只能单线程回放（并行复制只对部分事务有效），一旦写入量暴增，从库自然跟不上。
代理能做的,是感知延迟而不是消除延迟，比如在从库上跑一条轻量的探活SQL，比对主库位点和从库执行位点的差值，延迟超过阈值就把这个实例摘除，等追平了再放回来。
延迟感知路由的实现方式
配置延迟阈值时,把阈值设成500毫秒左右是常见做法，低于阈值的从库照常服务，超过阈值的从库自动下线，这个数值不能拍脑袋设成0，主从之间本身就有网络和回放的时间差，阈值设得太小会让从库频繁上下线，引发连接抖动。
MySQL 8.0以上环境，可以结合全局事务标识符做更精确的追平判断，代理在分发读请求前，检查请求是否携带了主库的最新事务ID，如果目标从库还没执行到这个位置，就换一个实例或者直接降级走主库。
连接复用对读写分布的影响
数据库代理连接池会复用后端连接,省去频繁建连的开销，但会话级状态会串味，一个连接经过代理被多个应用请求轮流使用，SET names utf8mb4、临时表、用户变量这些会话状态，上一个请求改了，下一个请求就遭殃。
如果应用对字符集或SQL模式有特殊要求,建议让代理开启连接初始化，每次复用前重置会话变量，这会给代理增加少量开销，但能避免“读到的数据刷新不出来”或“排序结果不对”这类诡异问题，很多团队排查半天读写分布，最后发现是连接串话，就是这个原因。
mysql读写分离代理怎么选：常用方案与配置实操
选代理方案,得看你的技术栈和运维能力，自建的和云托管的，差别很大。
主流代理方案横向对比
ProxySQL是不少团队的首选,支持规则灵活匹配、查询缓存、连接池管理，配置门槛偏高，需要理解mysql_servers、mysql_query_rules这些概念，MaxScale和MySQL Router是官方出身的方案，Router更轻，适合做故障转移和端口转发，但对复杂路由规则的支持弱一些，云数据库服务商自带的代理，胜在免运维、高可用托管，功能相对封闭。
| 方案 | 读写分离 | 延迟感知 | 配置复杂度 | 额外成本 |
|---|---|---|---|---|
| ProxySQL | 强 | 支持 | 中高 | 需要自建高可用 |
| MySQL Router | 中 | 弱 | 低 | 低 |
| MaxScale | 强 | 支持 | 中 | 需要自建高可用 |
| 云数据库代理 | 强 | 支持 | 低 | 按规格付费 |
ProxySQL的读写分组配置示例
实际操作中,在ProxySQL里做读写分离，核心是添加主从主机组并分配路由规则。
第一步,添加主库到写组，添加从库到读组，第二步，设置延迟阈值，ProxySQL会定期监控从库的复制延迟，超过阈值的自动标记为OFFLINE_HARD，不再接收流量，第三步，添加路由规则，把SELECT
语句按规则路由到读组，其他语句走写组。
这些操作通过INSERT和LOAD ... TO RUNTIME指令完成，配置生效是热加载的，不用重启代理，生产环境建议把规则用scheduler脚本固化下来，避免配置丢失后读写全打在主库。
数据库代理连接池配置参数的调整思路
连接池配置参数和负载均衡策略是协同工作的。max_connections决定代理能撑起多少前端连接，之后由代理复用后端连接，前端连接设得太大，后端的连接数会被打满，错误日志里全是Too many connections。
后端连接数的配置建议是前端的1/5到1/10，具体看单条SQL的执行时长，短查询占比高，可以适当压缩后端连接数；长时间运行的报表查询多，得多留后端连接余量。
代理本身带来的性能损耗与高可用问题
加点配置,再介绍代理不可忽视的成本，代理作为中间层，SQL解析和转发确实会带来性能损耗，静态规则匹配的损耗极低，解析SQL语法树的损耗相对高一些，对于大多数业务，代理的损耗在可接受范围内，但链路多一跳，延迟和故障点也会增多。
代理高可用是必须解决的问题,如果代理只有单节点，挂了就全站不可用，通常的做法是再部署一台备用节点，用虚拟IP漂移的方式做故障切换，也有的方案用LVS或Keepalived做代理层的前置负载均衡，把请求分发给多个代理节点。
数据库代理常见问题解答
数据库代理负载均衡策略是越复杂越好吗？
不是,大多数业务用加权轮询或最小连接数就足够，复杂策略比如基于响应时间的动态调整，会引入新的抖动因素，维护成本也高，从简开始，观察监控数据再加规则，是更稳妥的路径。
代理的读写分离一定保证读不到旧数据吗？
不一定,即使代理配置了延迟阈值，从库追平需要时间，极端情况下仍然存在读到旧数据的窗口，对数据一致性要求极高的场景，要在应用层做兜底，比如关键查询强制走主库，或使用短时缓存。
配置代理高可用需要额外采购负载均衡器吗？
云上环境通常直接使用云负载均衡产品挂载代理节点,自建机房可用Keepalived实现虚拟IP漂移，两种方案都能把单点故障的影响控制在秒级，具体选哪种取决于现有基础设施和运维投入。