Hyperf 中 MySQL 主从切换需基础设施协同完成，协程仅执行 SQL；连接池须设 connect_timeout=3.0、wait_timeout=5.0、max_idle_time≤30.0；读写分离需业务层显式控制，配合 MySQL 健康检测。

Hyperf 中 MySQL 主从切换不能靠协程自动感知或接管，协程本身不负责故障发现、VIP漂移或主从状态判断——它只负责高效执行 SQL。真正的切换逻辑必须由 MySQL 层和基础设施协同完成，协程化应用（如 Hyperf）需要做的是适配这种切换节奏，避免旧连接残留、读写错位和延迟放大。

主从切换时协程连接池的关键风险点
Hyperf 的 MySQL 连接池基于 Swoole 协程，所有连接在初始化后长期复用。一旦发生主从切换（比如主库宕机、VIP 漂移到新主），已建立的连接仍维持在原节点（可能已不可用），而协程不会主动断开或重连。常见问题包括：

• SELECT @@server_id 返回下线节点 ID，应用层无感知
• 读请求落到延迟几百秒的从库，返回过期数据
• 写请求发往只读从库，直接报错 ERROR 1290 (HY000)
• 连接池中空闲连接超时（默认 60 秒）未触发回收，导致切换窗口期内大量失败

Hyperf 连接池必须调整的三项参数
这些不是可选项，而是双主/主从高可用场景下的硬性要求：

• pool.connect_timeout 设为 3.0：防止协程在 TCP 连接阶段卡死，快速失败并触发重试逻辑
• pool.wait_timeout 提高到 5.0：避免获取连接时因池内暂无可用连接而长时间挂起
• pool.max_idle_time 严格设为 30.0 或更低：强制空闲连接 30 秒内释放，确保新请求能建立指向新主库的连接

读写分离需由业务层显式控制，不能依赖协程自动识别
Hyperf 不内置读写分离路由。你需要：

• 在配置中明确定义 write 和 read 两个连接池（如 mysql_write / mysql_read）
• 业务代码中手动指定连接：Db::connection('mysql_write')->insert(...) 或 Db::connection('mysql_read')->select(...)
• 对强一致性读（写后立刻读），统一走写库，或加 SELECT ... FOR UPDATE + 事务兜底

配合 MySQL 层健康检测，协程才真正“安全”
Keepalived 的 vrrp_script 必须调用真实检测脚本，不只是 nc -z：

• 执行 mysql -uhealth -p --connect-timeout=3 --execution-timeout=3 -e "SELECT 1"
• 同时校验 SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master
• 脚本返回非 0 时，Keepalived 才降级，否则 VIP 漂过去也没意义

不复杂但容易忽略。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载