hyperf连接池监控关注php进程内连接使用状态（如空闲/使用中连接数），数据库监控则反映mysql实例真实运行健康（如threads_connected、innodb_row_lock_time_avg）；二者必须结合交叉分析才能准确定位瓶颈，单看任一层面均易误判。
Hyperf 的连接池监控和数据库监控看的是两个层面的问题：前者关注 PHP 进程内连接的“使用状态”，后者反映 MySQL 实例本身的“运行健康”。光看一个，容易误判瓶颈位置。
连接池监控管什么
它只统计 Hyperf 自己维护的那一层连接资源，比如：
-
当前总连接数（
getCurrentConnections()）—— 池子里一共建了多少个连接 -
空闲连接数（
getConnectionsInChannel()）—— 多少个连接正等着被取走 - 正在使用的连接数 = 总数 − 空闲数 —— 反映瞬时并发压力
-
等待超时次数 —— 如果频繁触发
wait_timeout，说明池子不够用或请求堆积
这些指标全在 PHP 协程内存里，不涉及 MySQL 状态。即使 MySQL 已经锁死、慢查询满天飞，只要连接池里还有空闲连接，这些数字看起来可能依然正常。
数据库监控管什么
它直接读取 MySQL 的原生状态变量，暴露底层真实瓶颈，例如：
-
threads_connected—— 当前 MySQL 实际建立的连接总数，包括非 Hyperf 创建的连接（如 DBA 登录、其他服务） -
innodb_row_lock_time_avg—— 行锁平均等待时间，高值说明写冲突严重，PHP 层完全感知不到 -
slow_queries—— 慢查询累计次数，配合long_query_time配置判断索引是否失效 -
aborted_connects—— 连接被拒绝次数，可能因max_connections打满或认证失败
这类数据必须通过 mysqld_exporter 暴露，再由 Prometheus 抓取。Hyperf 自身的 hyperf_db_query_duration_ms 指标只记录 PDO 执行耗时，不包含排队、锁等待、DNS 解析、TCP 建连等环节。
为什么必须两者结合看
单看连接池，你可能以为“连接够用”，但实际是 MySQL 内部锁住了；单看数据库，你看到 threads_connected=120，却不知道其中 100 个来自 Hyperf，20 个是运维临时连接，得结合连接池配置才能判断是否该扩容。
- 当连接池 使用率持续 >90%，且
threads_connected接近max_connections→ 要调大池子上限，同时检查 MySQL 是否有连接泄漏 - 当连接池使用率不高，但
innodb_row_lock_time_avg > 50ms→ 问题在 SQL 或事务设计，不是连接数问题 - 当
aborted_connects上升，而连接池没报错 → 可能是账号权限不足或网络闪断，不是应用配置问题
真正的瓶颈定位，靠的是交叉比对：连接池告诉你“PHP 想要什么”，数据库监控告诉你“MySQL 实际给了什么、卡在哪里”。
