连接池显著优于直接连接：高并发下连接池通过复用连接省去TCP握手、认证等5–50ms开销，避免MySQL连接耗尽、OOM和连接泄漏，实测500+ QPS时直连易触发Aborted_connects或Too many connections错误，而连接池仍稳定运行。
直接对比连接池与直接连接的性能差异，关键不是看单次请求快多少，而是看高并发下系统整体吞吐、稳定性与资源消耗的变化。Hyperf 中连接池（如 hyperf/pool）和每次请求都新建 PDO 连接，本质是两种完全不同的连接生命周期管理方式，差异体现在 TCP 建连、认证开销、连接复用率、上下文切换和错误传播等多个层面。
连接池的核心优势：省掉重复建连成本
数据库连接建立包含 TCP 三次握手、SSL 协商（如启用）、MySQL 认证、权限检查、会话变量初始化等步骤，通常耗时 5–50ms（取决于网络延迟和 DB 配置）。Hyperf 的连接池在进程启动时就预热一批连接，后续协程复用已有连接，跳过全部建连流程。
- 连接池模式：一次建连 → 多次复用 → 连接空闲超时后自动回收
- 直连模式：每次请求都走完整建连流程 → 并发越高，建连线程/协程竞争越激烈 → 网络栈和 MySQL 认证模块压力陡增
- 实测典型场景：100 QPS 下，直连平均 DB 耗时可能比连接池高 8–12ms；当 QPS 上升到 500+，直连容易触发 MySQL 的
Aborted_connects或连接拒绝，而连接池仍可稳定运行
性能对比必须在相同条件下做压测
不能只改配置就下结论，需控制变量并观测多维指标：
- 统一使用相同数据库实例、相同查询语句（如
SELECT id FROM user LIMIT 1），排除慢查询或锁干扰 - 禁用所有中间件、AOP、日志采样，聚焦连接层本身
- 用
ab或hey发起固定并发（如 100、300、500）持续 60 秒压测，记录平均响应时间、P95/P99、错误率 - 同时采集服务端指标：
hyperf_db_pool_used_connections（连接池占用率）、hyperf_db_query_duration_ms（PDO 执行耗时）、mysql_global_status_threads_connected（MySQL 实际连接数）
直连模式暴露的真实问题往往被掩盖
表面看直连代码更“简单”，但实际隐藏了严重风险：
- 频繁创建/销毁连接导致 PHP 进程内存碎片化，长期运行后 GC 压力上升，Swoole Worker 可能因 OOM 被杀
- MySQL 侧
max_connections很快被占满，新请求收到Too many connections错误，而连接池可通过wait_timeout和排队策略平滑承接突发流量 - 没有连接健康检测，失效连接（如 MySQL kill 或网络闪断）无法自动剔除，直连会持续失败直到超时；连接池支持
detect_idle_time和max_idle_time主动清理 - 协程环境下直连易引发连接泄漏——一个协程异常退出未关闭 PDO，该连接就永远丢失；连接池有 borrow/release 显式契约，配合
finally可控释放
一个可落地的对比验证方法
不写新服务，直接改造现有接口做 A/B 测试：
- 分支 A：保持默认连接池配置（
min_connections=2, max_connections=10） - 分支 B：临时禁用连接池，在 DAO 层手动 new PDO（注意设置
PDO::ATTR_PERSISTENT => false模拟真实直连） - 用
go()启动 200 个并发协程循环调用同一接口 30 秒，观察 Hyperf Metrics 面板中hyperf_db_pool_wait_duration_ms（仅 A 有）和hyperf_db_query_duration_ms的分布差异 - 重点看 B 分支是否出现大量
SQLSTATE[HY000] [2002]（连接拒绝）或[HY000] [2013]（连接丢失）错误
