PDO持久化连接易致资源泄漏、状态残留和连接数失控，应禁用并采用短连接+连接池中间件或应用层复用等更安全方案。
PHP PDO 持久化连接（Persistent Connection）在特定场景下能减少连接开销，但不当使用会引发资源泄漏、状态残留、连接数失控等严重问题，实际生产中需谨慎评估。
连接池不可控，易耗尽数据库资源
PDO 持久化连接由 PHP 进程（如 Apache worker、FPM 子进程）维护，不会随脚本结束而关闭，而是被放入内部连接池复用。但 PHP 不提供连接池大小限制或空闲超时机制，导致：
- 高并发时每个 PHP 进程都持有一个独立的持久连接，数据库连接数呈“进程数 × 应用连接配置”线性增长
- MySQL 默认 max_connections 通常为 151，少量 FPM 进程（如 50 个）启用持久连接后就可能打满
- 连接长期空闲不释放，占用数据库内存和线程资源，影响其他应用或管理操作
连接状态残留，引发数据一致性风险
持久连接复用前不会自动重置会话状态，以下上下文可能跨请求污染：
- 事务未提交/回滚：上一个请求异常中断，遗留未完成事务，下一个请求复用该连接时可能意外继续或报错
- 临时表未清理：CREATE TEMPORARY TABLE 后未显式 DROP，下次复用时因表已存在报错
- 用户变量或会话变量（如 @var）残留：影响后续查询逻辑，尤其在存储过程或复杂 SQL 中难排查
- 字符集、SQL 模式、时区等会话级设置被上个请求修改且未还原
错误处理失效，掩盖真实问题
启用持久连接后，部分连接异常（如网络闪断、MySQL 主从切换、防火墙超时断连）不会立即暴露：
立即学习“PHP免费学习笔记（深入）”；
- PDO 默认不验证连接有效性，复用已断开的持久连接时，首次执行 SQL 才报错（如 “MySQL server has gone away”），错误延迟且难以定位源头
- 无法通过常规 try/catch 在连接建立阶段捕获问题，错误分散在业务 SQL 执行处，增加调试成本
- 连接池中混入半死连接，健康检查缺失，导致请求随机失败
替代方案更安全可控
现代部署环境下，推荐以下实践替代持久连接：
- 使用连接池中间件：如 ProxySQL、MySQL Router 或云厂商提供的代理层，具备连接复用、健康检测、限流熔断能力
- 短连接 + 连接复用优化：确保 PDO 构造时禁用 PDO::ATTR_PERSISTENT，依赖 MySQL 自身的 TCP keepalive 和快速建连能力（毫秒级）
- 应用层连接管理：在请求生命周期内复用单个 PDO 实例（非持久），配合连接超时（PDO::ATTR_TIMEOUT）和异常重试逻辑
- 监控与告警：实时跟踪数据库 Threads_connected、Aborted_connects 等指标，及时发现连接异常增长
不复杂但容易忽略：PDO 持久连接不是性能银弹，而是把连接管理责任从数据库推给了 PHP 进程，而 PHP 缺乏完善的连接生命周期治理能力。多数场景下，关闭持久化、做好连接复用和错误兜底，更稳定可靠。
