Symfony 8.1 和 Doctrine DBAL 均不支持内置连接池，所谓 pool_size 配置无效；真实连接管理依赖外部代理（如 ProxySQL）或 PDO 持久化，且后者在长生命周期环境中易引发连接泄漏与事务污染。
Symfony 8.1 本身不提供数据库连接池功能，Doctrine DBAL 也不内置连接池 —— 所有“连接池”需求必须由外部组件（如 PgBouncer、ProxySQL）或应用层自行管理。
为什么 Doctrine 不支持连接池
Doctrine DBAL 是一个轻量级抽象层，设计上遵循“按需创建连接 + 连接复用（PDO 持久化）”，而非维护独立的连接池。它没有连接预热、空闲超时、最大连接数限制等池控逻辑。
- 每次
$entityManager->getConnection()返回的Connection实例默认使用 PHP 的 PDO，底层连接由 PDO 自己缓存（仅限PDO::ATTR_PERSISTENT => true场景，且有严重风险） -
PDO::ATTR_PERSISTENT在 CLI/Swoole/Swoft 等长生命周期环境中极易引发连接泄漏、事务残留、状态污染 - Symfony 官方文档和 Doctrine 仓库中均无
connection_pool配置项、服务或扩展点
实际可用的替代方案
若你遇到高并发下 MySQL 连接数打满（Too many connections）、或希望降低建连开销，应从基础设施或架构层面解决：
- 用
ProxySQL（MySQL）或PgBouncer（PostgreSQL）部署在应用与数据库之间，配置transaction或session模式，对应用完全透明 - 在 Docker/K8s 中通过
initContainer或 sidecar 注入代理，把应用的DATABASE_URL指向本地127.0.0.1:6033（ProxySQL 默认端口） - 避免在 Symfony 中手动实现“池”：自己维护
Connection对象数组易导致事务隔离失败、未关闭连接、无法感知 DB 故障
DATABASE_URL 里哪些参数会影响连接行为
虽然不是连接池，但这些配置能间接缓解连接压力：
-
mysql://user:pass@127.0.0.1:3306/db?serverVersion=8.0&connect_timeout=10&read_timeout=30&max_lifetime=3600——max_lifetime是 DBAL 8+ 新增参数，控制连接最大存活秒数，超时后下次请求会新建连接 -
charset=utf8mb4必须显式加，否则某些版本 Doctrine 会跳过SET NAMES，导致 emoji 插入失败 - 不要加
&Persistent=1或&pdo[ATTR_PERSISTENT]=1：DBAL 不识别这类参数，PDO 层也不会生效
容易被忽略的陷阱
很多人以为改个配置就能“启用连接池”，结果卡在以下环节：
- 在
doctrine.yaml里硬写pool_size: 10—— 该字段不存在，Symfony 启动直接报错Unrecognized option "pool_size" - 用
php bin/console doctrine:database:create测试连通性，却没意识到这个命令只建库、不触发连接池逻辑（它压根不存在） - 在 Swoole 环境中启用
PDO::ATTR_PERSISTENT，结果多个协程共享同一连接，SELECT FOR UPDATE锁住全站
真正需要连接池的场景，得接受它是个独立运维组件，而不是一个 composer require 能解决的问题。
