PHP无原生连接池，高并发下需分场景选方案：PDO持久连接仅适用于低QPS的FPM场景，本质是进程级连接缓存，非真正池化；Swoole协程连接池是高并发唯一可控方案；ProxySQL等中间件适用于多语言共用数据库的复杂架构。
PHP本身不带原生连接池，高并发下直接新建连接必然触发 Too many connections 错误——这不是代码写得不够好，而是架构没对上。真正有效的优化必须分场景选方案，而不是堆配置。
PDO持久连接只适合低并发FPM场景
启用 PDO::ATTR_PERSISTENT => true 后，每个PHP-FPM worker进程会保留自己的连接，复用但不共享。它不是连接池，只是“连接缓存”。
- 适用场景：QPS max_connections > FPM子进程数 × 2）
- 致命风险：事务未提交、临时表未清理、会话变量残留，会导致后续请求读到脏数据
- 必须配套做两件事：
PDO::ATTR_EMULATE_PREPARES => false关闭模拟预处理；每次查询前手动执行SET NAMES utf8mb4和ROLLBACK - 别信“加了 persistent 就万事大吉”——FPM重启或worker异常退出时，连接可能滞留在MySQL端，需靠
wait_timeout回收，而默认值是28800秒（8小时）
Swoole协程连接池是高并发唯一靠谱路径
只有在常驻内存、协程调度的环境下，才能实现连接的真正复用和可控生命周期。Swoole 5.0+ 的 Swoole\ConnectionPool 是目前最轻量且稳定的方案。
- 初始化时固定创建连接数，比如
new Swoole\ConnectionPool(function() { return new Co\MySQL(); }, 64)，64是硬上限，不是建议值 - 连接获取必须用
$pool->get()，归还必须用$pool->put($conn)，漏掉任意一步就泄漏 - 不要在协程外调用
get()——会阻塞整个进程；也不要跨协程传递连接对象，协程销毁后连接句柄失效 - 配合
Co\WaitGroup控制并发请求数，避免瞬间打爆池容量，例如限制同时最多10个SQL请求排队
ProxySQL这类中间件不是银弹
把连接池从应用层剥离到中间件，听起来很美，但实际引入了额外网络跳转、单点故障和配置复杂度。
立即学习“PHP免费学习笔记（深入）”；
- 仅当已有多个语言服务共用同一套MySQL、且无法统一改造应用时才考虑
- ProxySQL的
mysql_servers表必须设max_connections，否则它自己会成为瓶颈 - PHP连接串要改成
host=127.0.0.1;port=6033（ProxySQL监听端口），而非直连MySQL的3306 - 所有连接超时参数（
connect_timeout_server,max_connect_error）都得在ProxySQL里重配，和PHP侧的PDO::ATTR_TIMEOUT无关
连接数配额必须双向对齐
再好的池子，如果上下游配额错位，照样崩。关键不是“池开多大”，而是“谁说了算”。
- MySQL端：确认
max_connections值，减去系统保留连接（通常10–20个），剩余才是可用额度 - PHP侧：FPM模式下，
pm.max_children× 每worker最大连接数 ≤ MySQL可用额度；Swoole模式下，池容量 ≤ MySQL可用额度 - 别忽略监控：用
SHOW STATUS LIKE 'Threads_connected'实时看MySQL当前连接数，比日志报错早10秒发现问题 - 最易被忽略的一点：Swoole服务启动后，首次请求才会真正建立连接，所以压测前必须预热，否则首波请求全卡在连接建立上
