Hyperf MySQL长连接靠连接池与主动维护机制协同实现，需校准wait_timeout、max_idle_time和heartbeat三个参数；min_connections不宜为0；心跳用PING而非SELECT 1；微服务需按等级配额隔离连接。
Hyperf 中 MySQL 长连接不是“建完就一直用”，而是靠连接池 + 主动维护机制协同实现的。关键不在于“保持不断开”，而在于连接在需要时可用、闲置时及时清理、失效前主动探测并替换。
必须配对校准三个核心参数
MySQL 服务端有 wait_timeout（默认通常 300 秒），它决定了空闲连接被服务端强制断开的时间。Hyperf 连接池必须在这个时间点之前完成自我管理，否则取出来的连接大概率已失效。
先查 MySQL 实际值：
SHOW VARIABLES LIKE 'wait_timeout';-
再设 Hyperf 的两个池参数（以
wait_timeout=300为例）：-
max_idle_time => 270：连接空闲超 270 秒就从池中移除，严格小于服务端值，留出缓冲； -
heartbeat => 135：后台空闲检查线程每 135 秒对池中闲置连接发一次PING，确认是否还活着。
-
⚠️ 注意：
heartbeat => true不生效，必须填具体秒数（如135）；设为-1或false等同于关闭检测。
min_connections 别设为 0
min_connections 是服务启动时预热建立的最小连接数。设为 0 表示冷启动时一个连接都不建，首次请求需临时创建，增加延迟，也容易在突发流量下触发连接争抢。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 生产建议设为
2～5，保障基础可用性； - 同时配合
max_connections做合理上限（例如32），避免单服务耗尽 DB 总连接数。
心跳用 PING，别手改 SELECT 1
Hyperf 默认使用 PDO::getAttribute(PDO::ATTR_CONNECTION_STATUS) 或底层驱动的 ping() 方法，轻量高效。SELECT 1 会走完整 SQL 解析、权限校验、执行器流程，性能差 3–5 倍，且可能因慢日志或审计策略被拦截。
- 不需手动干预，只要驱动是标准 PDO_MySQL 或 MySQLi 就支持；
- 若不确定，可写个简单命令验证：
var_dump($this->db->connection()->getPdo()->ping());—— 返回true即可用。
微服务场景要配额隔离
多个 Hyperf 服务共连一个 MySQL 时，不能各自随意设 max_connections => 100。必须按服务等级分配连接额度：
- 核心服务（如订单）：占 40%；
- 查询类服务：限 15%；
- 定时任务类：强制
max_connections => 5； - 所有服务的
max_idle_time统一 ≤ 240 秒（推荐180），防止 Sleep 连接堆积。
验证方式：低峰期执行
SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host ORDER BY COUNT(*) DESC;
看是否有某个服务异常占满连接。
不复杂但容易忽略。
