Hyperf不内置MySQL集群自动路由与故障转移，需按场景适配：主从读写分离需自定义ConnectionResolver；MGR集群须依赖MySQL层状态并强化连接池参数；ProxySQL/MaxScale代理方式最实用，Hyperf只需单机式配置。
Hyperf 本身不内置 MySQL 集群（如 MGR、InnoDB Cluster、ProxySQL 后端集群或双主 VIP 架构）的自动路由与故障转移能力。所谓“配置 MySQL 集群连接”，本质是在应用层适配集群语义：明确读写分离策略、连接容错机制、健康感知方式，并通过连接池参数与运行时逻辑协同控制行为。
下面分三类典型集群场景说明配置要点：
✅ 场景一：MySQL 主从读写分离（推荐用 hyperf/db-connection + 自定义 Router）
Hyperf 原生不支持自动读写分离，需配合 hyperf/db-connection 扩展包 + 自定义 ConnectionResolver 实现：
- 在
config/autoload/databases.php中定义多个连接（如mysql_master和mysql_slave） - 安装并启用
hyperf/db-connection - 编写
App\Database\ReadwriteConnectionResolver，继承Hyperf\DbConnection\ConnectionResolver，重写resolve()方法，根据当前操作类型（SELECT/INSERT/UPDATE/DELETE）返回对应连接 - 在模型或查询构造器中显式调用
DB::connection('master')或DB::connection('slave')，或通过 AOP 拦截 SQL 类型自动路由
注意：事务内所有操作必须走 master，否则会破坏一致性；
transaction()默认绑定到默认连接，需手动指定DB::connection('master')->transaction(...)
✅ 场景二：MGR（MySQL Group Replication）单写多读集群
MGR 是强一致性集群，但只允许一个节点写入（primary），其余为 secondary（只读）。Hyperf 需做到：
禁止在 secondary 节点执行写操作：应用层不做自动切换，而是依赖 MySQL 层的
group_replication_primary_member状态 + Keepalived/VIP 或 DNS 轮询指向当前 primary
MySQL8 CRM Schema Design Expert下载面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
连接池配置强化健壮性：
-
pool.connect_timeout设为3.0（避免 VIP 切换期长时间阻塞） -
pool.max_idle_time≤ MySQL 的wait_timeout（建议设为25920即 7.2 小时，但不超过服务端值） -
pool.heartbeat开启，check_interval≥3000（Swow/Swoole 强制要求）
-
不推荐直接填多个 host：Hyperf 连接池不解析逗号分隔 host，也不会自动 failover；若硬要轮询，须自行封装
ConnectionInterface并实现重试+健康检查逻辑
✅ 场景三：ProxySQL 或 MaxScale 前置代理层（最实用的集群接入方式）
将集群拓扑隐藏在中间件后，Hyperf 只需像连单机一样配置：
-
host填 ProxySQL 地址（如10.0.1.100），port填其监听端口（如6033） - 关闭 SSL（除非 ProxySQL 显式终止 SSL）或按其要求配置 CA
- 连接池参数按常规设置（
max_connections建议 20–50，依据 QPS × 平均耗时 × 2 估算） - 由 ProxySQL 负责：
- 自动识别写请求发往 primary
- 读请求负载均衡到 healthy 的 secondary
- 实时检测后端节点状态，自动摘除异常实例
- 支持平滑权重、慢查询熔断、SQL 重写等高级能力
✅ 优势：Hyperf 配置零改造，运维与业务解耦，故障恢复快，适合生产环境
不复杂但容易忽略
