应将 Hyperf 的 max_idle_time 设为 wait_timeout 减 5 秒且不低于 10 秒，确保连接池在数据库关闭前主动释放空闲连接，避免获取“僵尸连接”导致 MySQL server has gone away 错误。
因为连接池里的空闲连接如果比数据库主动断开的时间还晚，就会变成“僵尸连接”——表面还活着，实际一用就报 MySQL server has gone away。
连接池和数据库的“心跳节奏”要对齐
MySQL 的 wait_timeout 是服务端参数，表示一个空闲连接最长能保持多久不操作，超时后服务端会直接关闭它。Hyperf 的 max_idle_time 是客户端连接池参数，表示连接在池中空闲多久后主动释放。
如果 max_idle_time ≥ wait_timeout，连接池可能把一个已被 MySQL 关闭的连接继续留着，下次取出时立刻失败。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
典型报错场景
- 协程从 Redis 连接池拿到连接，执行完又归还；但紧接着调用 DB 查询，却在 DB 操作中抛出
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away - 日志里没看到 MySQL 主动断连记录，但 DB 操作频繁失败，且多发生在低流量时段
- DB 连接数监控显示 ESTABLISHED 数稳定，但错误率随时间缓慢上升
安全配置建议
设 max_idle_time = wait_timeout − 5 秒是常见做法。例如：
- MySQL
wait_timeout = 60→ Hyperfmax_idle_time = 55 - MySQL
wait_timeout = 300（5分钟）→ Hyperfmax_idle_time = 295
同时确保 max_idle_time 不小于 10 秒，避免连接过于频繁地创建销毁。
配套检查不能少
- 确认 MySQL 实际生效的
wait_timeout：登录后执行SHOW VARIABLES LIKE 'wait_timeout';，注意区分全局值与会话值 - 检查 Hyperf 配置是否被多处覆盖：比如
config/autoload/database.php和环境变量都设置了max_idle_time - 观察连接池真实空闲行为：开启
pool.idle_check_interval（如设为 3000ms），配合日志确认连接是否按时清理
