必须结合hyperf连接池指标（如hyperf_db_pool_connections_active）与mysqld_exporter的mysql_global_status_threads_connected、aborted_connects交叉验证，才能准确定位压测时连接池瓶颈，单看任一端指标均可能误判。
压测时监控连接池连接数，不能只看容器或进程级指标，得拿到应用内部连接池的实时状态，比如活跃连接（Active）、空闲连接（Idle）、最大容量（Max）这些关键数字。
暴露连接池指标端点
Hyperf 默认不直接暴露连接池状态，需主动集成 Prometheus 指标上报：
- 启用
hyperf/metric组件，并确保use_standalone_process => true，避免指标采集被业务协程阻塞 - 在
config/autoload/metric.php中开启数据库和 Redis 池相关指标，例如设置'collectors' => ['db', 'redis'] - 连接池指标会以
hyperf_db_pool_connections_active、hyperf_redis_pool_connections_idle等形式出现在/metrics接口 - 手动访问
curl http://127.0.0.1:9502/metrics | grep pool_connections验证是否输出有效数据
对接 Prometheus 抓取与告警
光有指标还不够，得让监控系统持续采集并识别异常趋势：
- Prometheus 的 job 配置中，
targets必须指向 Hyperf 实例的真实可访问地址（如容器内用host.docker.internal:9502，K8s 中用 Service DNS） - 设置合理抓取间隔（建议
scrape_interval: 15s），太短会增加服务负担，太长则错过峰值波动 - 在 Grafana 中配置面板，用 PromQL 查看连接池水位，例如：
avg by (pool_name) (hyperf_db_pool_connections_active)sum(hyperf_redis_pool_connections_idle) / sum(hyperf_redis_pool_connections_max) - 设置阈值告警：当
hyperf_db_pool_connections_active / hyperf_db_pool_connections_max > 0.9持续 1 分钟，触发“连接池接近耗尽”告警
Swow 环境下需额外确认池参数生效
如果项目已升级 Swow 协程引擎，旧的连接池配置会被忽略，必须校验是否真正启用了新池：
- 检查
config/autoload/databases.php中 MySQL 配置是否已删除旧pool键，并新增 Swow 专用结构，含min_connections和max_connections - 启动后查看日志或执行
php bin/hyperf.php server:watch，确认输出含Swow\Coroutine\Channel字样 - 强制清空
runtime/container目录再重启，防止旧 Pool 实例缓存干扰 - Swow 的
check_interval必须 ≥3000ms，否则心跳检测异常会导致 idle 连接无法回收，压测中表现为连接数缓慢爬升不回落
配合 mysqld_exporter 做交叉验证
仅看 Hyperf 上报的连接池指标可能掩盖真实瓶颈，需同步观察 MySQL 侧实际连接状态：
- 部署
mysqld_exporter，采集mysql_global_status_threads_connected（当前总连接数）和mysql_global_status_aborted_connects（拒绝连接数） - 对比
hyperf_db_pool_connections_active与mysql_global_status_threads_connected：若后者显著更大，说明存在连接泄漏或未复用 - 若
mysql_global_status_aborted_connects持续增长，结合 Hyperf 日志中的 PDO 连接超时，基本可判定是max_connections到达上限，而非应用层池配置不足
