ThinkPHP本身无连接池，优化核心是延迟初始化、连接复用（deploy=>1）与防泄漏；Db::connect()仅返回未建连实例，真实连接在select()/find()等执行时建立，需避免误触发、手动close及配置完整。
ThinkPHP 本身没有连接池，所谓“优化数据库连接”实际是控制连接建立时机、复用已有连接、防止连接泄漏，核心目标是避免 Too many connections 和 SQLSTATE[HY000] [2002] Connection refused 这类报错。
Db::connect() 是延迟初始化，但容易被误触发建连
ThinkPHP 的 Db::connect() 返回的是一个未真正发起 TCP 连接的 Connection 实例，真实连接只在首次执行 SQL（如 select()、find()、value()）时才建立。很多人误以为 Db::table('user')->where('id', 1) 就已连上数据库，其实不会。
- 安全写法：把构建和执行分开，只在真需要数据时才调执行方法
- 危险操作：在循环里反复写
Db::table()->select()，哪怕条件相同，每次都会走完整连接流程（除非配置了deploy => 1且配置完全一致） - CLI 或 Swoole 场景下，
Db::table()->where()->select()执行完连接不会自动释放，必须手动Db::close()或 unset
deploy => 1 是连接复用的关键开关，不是“连接池”
TP6/TP8 中 deploy => 1 并不启用连接池，而是开启同配置连接的单例复用机制——对相同 host/port/database/user 的请求，共享同一个 PDO 实例。它在 FPM 和 Swoole 下都生效，但前提是配置项不能缺。
- 必须显式配置
'deploy' => 1，默认是 0（关闭复用） - 漏写
'type' => 'mysql'或'hostname'会导致 fallback 到 default 配置，复用失效且不易察觉 - 跨库操作（如
Db::connect('log_db')）会新建连接，和主库完全隔离 -
'pool_size' => 20可限制空闲连接数，但仅在deploy => 1生效，且 TP 不自动清理空闲连接
Swoole 常驻进程下连接数失控，必须手动干预
FPM 每次请求结束自动关连接，Swoole 却不会——连接对象常驻内存，反复调用 Db::table()->select() 会不断累积 PDO 实例，直到 MySQL 拒绝新连接。
立即学习“PHP免费学习笔记（深入）”；
- 所有 CLI 命令末尾加
Db::close()，不要依赖框架自动回收 - Swoole 任务中，避免在
__construct或同步中间件里提前调Db::connect()，应在协程内用go(function () { ... }) - 事务内连接不会归还池中，
Db::transaction()必须在同一个协程上下文执行，否则连接被销毁 - MySQL 的
wait_timeout默认 8 秒，闲置连接会被 kill，需配心跳：'options' => ['heartbeat' => 3]，并同步调大服务端SET GLOBAL wait_timeout = 300
别碰 'persistent' => true，它在 TP 里基本无效且危险
TP 底层用 PDO，'persistent' => true 实际触发 PDO::ATTR_PERSISTENT，但在 FPM 下极易引发状态污染（未提交事务、临时表残留），且 TP 的 __destruct 会主动置空 $this->pdo，让持久化失效。
- TP5/TP6 默认就是
'persistent' => false，检查 config/database.php 别被手动改过 - mysqli 驱动下
'pconnect' => true有效，但 TP 官方不维护 mysqli 连接器，稳定性无保障 - 盲目调大 MySQL 的
max_connections是掩耳盗铃，先用SHOW PROCESSLIST看清哪些连接是 Sleep、哪些是 Query、哪些 Time 超长 - 真正瓶颈通常是 PHP-FPM 的
pm.max_children—— 每个子进程持有一个连接，这个值设太高，MySQL 连接数直接打满
复杂点在于：连接复用逻辑高度依赖运行模型（FPM/Swoole）、配置完整性、以及是否踩进事务/多库/CLI 这些边界场景。最容易被忽略的是——你以为没建连的操作（比如只链式调用 where()），其实完全没问题；而你以为复用了连接的地方（比如换了配置名却漏写 type），可能早就在连别的库了。
