hyperf不支持多数据库连接的负载均衡，仅支持多库切换；负载均衡仅适用于同一数据库的多个实例（如主从、集群），需结合连接池、服务发现与负载算法实现。
Hyperf 本身不为“多数据库连接”提供负载均衡，它只支持多库切换；真正的负载均衡发生在 同一数据库的多个实例之间（比如主从读写分离、分片集群、高可用主备），需结合连接池、服务发现与负载算法协同配置。混淆“多库”和“多实例”是常见误区。
明确场景：哪些情况需要负载均衡
多数据库连接（如 log_db、report_db）是逻辑隔离，彼此独立，不存在负载分发；而负载均衡只适用于：
- 同一个业务库部署了多个只读副本（MySQL 主从），希望读请求分散到不同从库
- PostgreSQL 集群有多个可读写节点（如 Citus 或 Patroni），需按策略分发写/读流量
- 跨机房部署的同名数据库，通过注册中心动态感知健康实例
此时，不是配多个 connections，而是把同一逻辑库的多个物理地址，以 服务发现 + 负载算法 方式注册为一个“虚拟数据源”。
主从读写分离下的连接池级负载配置
Hyperf 不内置读写分离代理，但可通过自定义连接池 + 运行时路由实现。关键在 config/autoload/database.php 中为同一逻辑库配置多个节点，并启用 read_write_split 模式：
- 设置
'driver' => 'mysql'下的'read_write_split' => true - 在
'read' => [ [...], [...] ]和'write' => [ [...] ]中分别填入从库与主库地址 - 每个节点可配置
'weight'控制读流量比例（如['host'=>'s1','weight'=>2]分得双倍读请求） - 配合
'load_balancer' => 'random'或'roundrobin'实现从库间负载
注意：该模式下 Db::connection('default') 自动识别读/写上下文，无需手动切 connection 名。
注册中心驱动的多实例负载（推荐用于生产）
当数据库本身支持服务注册（如 TiDB with PD、或自建 MySQL Proxy 注册到 Nacos），可让 Hyperf 消费者动态发现节点：
- 在
config/autoload/services.php中声明数据库服务消费者，例如：'name' => 'mysql-cluster' - 开启服务发现：
'enable.discovery' => true - 指定负载算法：
'load_balancer' => 'least_conn'（适合长连接稳定场景）或'consistent_hash'（需会话粘性） - 业务中用
Db::connection('mysql-cluster')—— 此时 connection 名对应的是服务名，不是静态配置名
该方式天然支持故障剔除与自动扩缩容，比硬编码 IP 更健壮，尤其适合 VPC 内混合云部署。
连接池参数必须联动调优
负载均衡效果会被不合理连接池参数抵消。重点调整三项：
-
max_connections：设为 DB 侧max_connections的 70% 以内，避免打满服务端 -
wait_timeout：从默认 3.0 秒提升至 5.0～8.0 秒，缓解突发流量排队 -
max_idle_time：设为略小于 MySQL 的wait_timeout（如 55 秒），防止连接被服务端主动断开
同时开启连接池监控，关注 hyperf_db_pool_used_connections 指标是否长期贴近上限——这是负载不均或泄漏的直接信号。
