ci4原生不支持数据库连接池，pconnect=true仅启用不可靠的php持久连接；真正方案是引入proxysql等代理层或独立连接池服务，而非修改框架配置。
CodeIgniter 4 原生不支持数据库连接池，强行配置 pconnect 或修改 dbdriver 为 pdo 并不能实现真正的连接复用——它只是启用了 PHP 的持久连接（persistent connection），而该机制在 FPM 环境下实际不可靠，且无法控制最大连接数、空闲超时等关键参数。
为什么 CI4 的 pconnect = TRUE 不是连接池
CI4 的数据库配置中设置 'pconnect' => TRUE 仅触发 PDO 或 MySQLi 的底层持久连接行为。但问题在于：
- FPM 进程重启或超时时，持久连接会被销毁，池状态无法维持
- 没有连接校验（validationQuery）、空闲回收（idle eviction）、等待队列阻塞控制
- 并发激增时仍可能耗尽 MySQL 的
max_connections，报错SQLSTATE[HY000] [1040] Too many connections -
database.php中所有参数（如maxTotal、minIdle）均被忽略，框架根本不读取这些字段
CI4 中真正可用的连接池替代方案
必须引入外部连接池中间件，而非修改 CI4 配置文件。常见可行路径有两条：
-
代理层方案：部署
mysql-proxy或ProxySQL，让 CI4 连接本地代理，由代理管理后端真实连接池。配置简单、零代码改动，适合已有项目。注意 ProxySQL 的mysql-pool_idle_time和mysql-default_max_connections必须显式调大 -
应用层封装方案：用独立服务（如 Go/Java 编写的连接池服务）暴露 HTTP/gRPC 接口，CI4 通过
cURL或Guzzle提交 SQL 请求。适合对安全与审计要求高的场景，但增加网络延迟和运维复杂度
不推荐尝试“自己写 PDO 连接池类注入 CI4”，因为 CI4 的 DB 类强绑定于 Connection 实例生命周期，无法替换底层连接获取逻辑，硬塞会导致事务失效、查询构建器（Query Builder）异常中断。
如果坚持用 CI4 原生方式压测优化
虽非连接池，但可缓解高并发下的连接压力：
- 将
'pconnect' => FALSE（默认值），改回FALSE—— 听起来反直觉，但 FPM 下TRUE反而因进程间共享混乱导致更多连接泄漏 - 在
app/Config/Database.php中调低'port'（如从 3306 改为自定义端口），配合 MySQL 的wait_timeout设为 30 秒，加速连接释放 - 用
$this->db->close()主动关闭不再需要的连接，尤其在长循环或异步任务中；否则连接会滞留到脚本结束 - 避免在模型构造函数里执行查询，防止每次 new Model 就新建连接；改用依赖注入或 service 定义懒加载
真正要跑出高吞吐量，别在 CI4 配置里找连接池开关——它不存在。要么加代理层，要么换框架（如 Laravel + Laravel Octane + Swoole Redis 连接池驱动），否则所有“调参”都只是在掩盖架构瓶颈。
