pconnect = TRUE 不建议开启，因其易导致连接泄漏、超时及并发阻塞；应保持 FALSE，配合查询缓存、严格模式、utf8mb4 字符集及索引优化提升性能。
pconnect 设为 TRUE 确实能减少连接建立开销，但**在大多数 CodeIgniter 部署场景下，它反而会引发连接泄漏、超时或并发阻塞，不建议直接开启**。真正有效的性能提升，来自对连接行为的精准控制，而非简单打开“长连接”开关。
为什么 pconnect = TRUE 在 CI3 中容易出问题
CodeIgniter 3 的 pconnect 依赖 PHP 的 MySQLi 或 PDO 的底层持久连接机制，而该机制与 Apache 的 prefork MPM 或 PHP-FPM 的 worker 模型存在隐式冲突：
- 每个 PHP 进程/线程会缓存一个连接，进程复用时连接不会自动释放或验证有效性
- 数据库服务器端空闲连接超时（如 MySQL 的
wait_timeout）后，CI 不会自动重连，后续查询直接报MySQL server has gone away - 连接数可能远超预期，尤其在高并发下触发
max_connections限制 - CI3 的
$this->db->close()对持久连接无效，无法手动清理
替代方案：用连接池思路控制连接生命周期
与其依赖不可控的底层持久化，不如在应用层主动管理连接复用粒度。推荐以下组合策略：
- 保持
pconnect=FALSE（默认），避免进程级连接污染 - 在
database.php中调高cache_on并配合cachedir，缓存查询结果而非连接本身 - 对高频只读接口，用
$this->db->cache_on()+cache_all()显式启用查询缓存 - 若必须复用连接（如 CLI 批处理脚本），改用
$this->load->database('group_name', TRUE)的第二个参数——它返回独立 DB 实例，可显式->close()，且不干扰主连接
真实生效的配置项调整清单
以下修改直接作用于 application/config/database.php，无需额外扩展库：
-
'db_debug' => ENVIRONMENT !== 'production'：生产环境务必关掉，避免异常堆栈暴露连接细节 -
'save_queries' => FALSE：关闭查询日志记录，减少内存占用（尤其搭配大量get()时） -
'stricton' => TRUE：启用严格模式，让 MySQL 提前报错，避免因隐式类型转换导致的全表扫描 -
'failover' => array()：留空即可；若需多实例容灾，才填入备用主机数组，不要为单机环境强行加空数组 -
'char_set' => 'utf8mb4'和'dbcollat' => 'utf8mb4_unicode_ci'：确保字符集兼容 emoji 和四字节 UTF-8，避免因编码不一致触发隐式转换和索引失效
最后提醒一个容易被忽略的点
数据库性能瓶颈往往不在连接建立，而在查询本身。开启 save_queries 后观察 $this->db->queries，你会发现多数耗时来自未加索引的 WHERE 字段、缺少 EXPLAIN 分析的 JOIN，或模型中反复执行的相同查询。比起纠结 pconnect，优先检查 get_where() 是否用了复合条件索引，以及是否把本该在 Model 层一次查完的数据，拆成 N+1 次 get() 放在循环里执行。
