Hyperf 中 MySQL 主从切换需基础设施协同完成，协程仅执行 SQL；连接池须设 connect_timeout=3.0、wait_timeout=5.0、max_idle_time≤30.0；读写分离需业务层显式控制，配合 MySQL 健康检测。
Hyperf 中 MySQL 主从切换不能靠协程自动感知或接管，协程本身不负责故障发现、VIP漂移或主从状态判断——它只负责高效执行 SQL。真正的切换逻辑必须由 MySQL 层和基础设施协同完成，协程化应用（如 Hyperf）需要做的是适配这种切换节奏，避免旧连接残留、读写错位和延迟放大。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
主从切换时协程连接池的关键风险点
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 漂过去也没意义
不复杂但容易忽略。
