压测前必须确认MySQL的max_connections、wait_timeout和Threads_connected三个硬限制，它们共同决定Hyperf连接池参数合法范围，漏查任一都将导致调参失效。
压测前必须确认的三个数据库侧硬限制
Hyperf 压测连不上、报 Too many clients 或 MySQL server has gone away，90% 是因为没先查清数据库本身的天花板。别急着调 pool.max_connections，先登录 MySQL 执行：
-
SHOW VARIABLES LIKE 'max_connections';—— 这是服务端总连接数上限，阿里云 RDS 默认 200～500，本地 Docker 镜像常为 151 -
SHOW VARIABLES LIKE 'wait_timeout';—— MySQL 主动断开空闲连接的时间（单位秒），默认 28800（8 小时），但线上常被调成 60～300 -
SHOW STATUS LIKE 'Threads_connected';—— 当前已建立连接数，压测中若持续 > 90% 的max_connections，说明池子真不够，不是参数错
这三个值决定了 Hyperf 连接池所有参数的合法范围，漏查任何一个，后续调参都是空中楼阁。
pool.max_connections 和 wait_timeout 必须联动设
单独改 max_connections 或单独拉高 wait_timeout 都会引发新问题。真实压测中常见组合错误：
- 设
max_connections = 100但wait_timeout = 1.0：协程排队不到 1 秒就抛WaitTimeoutException，日志刷屏，但实际连接池可能只用了 30 个 - 设
wait_timeout = 10.0却不加max_connections：请求卡住 10 秒才失败，掩盖了连接泄漏或慢 SQL 真实瓶颈 - 推荐生产压测初始值：
max_connections ≈ 峰值 QPS × 平均 DB 耗时（秒） × 1.5，再向下取整到 10 的倍数；wait_timeout设为5.0（不能低于 3.0，也不建议高于 8.0）
例如压测目标 200 QPS、平均查询 0.06s → 理论需 12 个连接 → 建议从 max_connections = 40、wait_timeout = 5.0 起步，观察 Threads_connected 和 WaitTimeoutException 日志比例再迭代。
max_idle_time 和 heartbeat 配错会让“心跳”完全失效
很多人开了 heartbeat 还是报 gone away，是因为没理解 Hyperf 的空闲检查机制：真正的后台探测靠的是 IdleConnectionChecker 线程，它只认 max_idle_time，而 heartbeat 只是该线程每次探测时发的语句。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
max_idle_time必须 严格小于 MySQL 的wait_timeout，建议设为wait_timeout - 30（如 MySQL 是 60，则设 30） -
heartbeat应 ≤max_idle_time，推荐设为max_idle_time / 2（如 max_idle_time=30，则 heartbeat=15） - 若
max_idle_time > wait_timeout：连接在池里“睡过头”，取出时必然已断，触发重连失败或直接异常 - 若
heartbeat太小（如 5）：每 5 秒全量 ping 一次，压测时可能打满数据库的 PING 并发
这个组合一旦配反，压测中会出现大量偶发性连接失败，且错误日志分散，极难定位。
压测中验证连接是否泄漏的两个实操动作
连接池参数再合理，也扛不住代码层泄漏。压测时如果 Threads_connected 持续上涨不回落，或 pool.getCurrentConnections() 返回值远高于 pool.getConnectionsInChannel()，基本可判定泄漏。
- 重点检查
$mysql->transaction()或$redis->pipeline()后是否都执行了commit()/exec()；中间 throw 异常未 catch 会导致连接被协程锁死直到结束 - 在关键 DAO 方法前后加日志：
Context::has($db->getContextKey())判断当前协程是否已持有连接，避免重复获取 - 临时开启
pool.min_connections = 2（不要设 0），冷启后立即观察 ESTABLISHED 连接数是否从 2 开始增长——若起步就是 50+，说明有长连接或定时任务提前占坑
真正稳定的连接池，不是靠参数堆出来的，而是泄漏路径被逐条堵死之后，参数才有意义。压测中途发现连接数缓慢爬升，优先停掉业务逻辑，只跑空循环 + 连接获取/释放，才能快速归因。
