php持久化连接需谨慎使用：仅在高并发、连接耗时长、同机部署等特定条件下有益；否则易引发锁残留、事务未提交、变量污染等问题。mysqli须用“p:”前缀启用，pdo通过pdo::attr_persistent控制，但均不跨fpm进程共享，且自动清理不重置自定义会话变量。
PHP持久化数据库连接不是“开了就变快”，而是特定条件下才值得用——比如高并发、连接建立耗时长、MySQL服务器与PHP同机部署；但若应用本身事务密集、会话状态复杂，或FPM子进程复用率低，它反而会引入锁残留、事务未提交、变量污染等隐性故障。
mysqli 持久连接必须加 p: 前缀
mysqli 不像 PDO 那样靠配置项开关，它靠主机名前缀识别是否启用持久连接。漏掉这个前缀，mysqli_connect() 会静默降级为普通连接，毫无报错提示。
-
mysqli_connect('p:localhost', $user, $pass)✅ 正确开启 -
mysqli_connect('localhost', $user, $pass)❌ 普通连接，即使你期望持久 - 如果用
mysqli_real_connect()手动建连，$host参数同样要带p: - DNS解析慢时，
p:127.0.0.1比p:localhost更可靠（避免额外的域名解析开销）
PDO 的 PDO::ATTR_PERSISTENT 是布尔开关，但有陷阱
设为 true 确实启用持久连接，但它只在连接初始化时生效，后续无法动态切换；更关键的是，PDO 的持久连接**不跨 FPM worker 进程共享**——每个 PHP-FPM 子进程维护自己的连接池。
- 配置示例：
new PDO('mysql:host=localhost;dbname=test', $u, $p, [PDO::ATTR_PERSISTENT => true]) - 如果 FPM 配置了
pm.max_children = 50，最多可能有 50 个独立的 MySQL 连接，而非“一个连接被所有人复用” - 若脚本中手动调用了
$pdo->beginTransaction()却没commit或rollback，该连接归还池时会被自动回滚——这是 mysqli 也做的清理动作，但 PDO 不会帮你重置自定义会话变量（如SET @var = 1） - 连接池里“干净”的定义是：事务已回滚、临时表已删、锁已释放——但不会清空用户自定义的 session 变量或 SQL mode 变更
持久连接的副作用比想象中更隐蔽
最常被忽略的问题不是连接没复用，而是复用了一个“带病”的连接：上一个请求留下的锁、未关闭的游标、错误的字符集设置、甚至 SELECT ... FOR UPDATE 后崩溃导致的行锁未释放，都会直接传染给下一个使用它的请求。
- MySQL 的
SHOW PROCESSLIST中看到大量Sleep状态连接，并不意味着它们健康；可能正卡在等待行锁 - 当出现“Deadlock found when trying to get lock”却查不到明显并发写操作时，优先怀疑持久连接残留的事务上下文
- 如果你的应用依赖
SET NAMES utf8mb4或SET time_zone = '+08:00'，这些设置不会被 mysqli/PDO 的自动清理重置，必须每次连接后显式执行 - PHP-FPM 的
pm.max_requests设置过小（如默认 0 或 1000），会导致 worker 频繁重启，持久连接根本来不及复用几次就被销毁
真正决定要不要开持久连接的，不是“听说它快”，而是看你的 mysqladmin status | grep Threads_connected 在高峰时是否频繁飙升、单次连接建立平均耗时是否超过 10ms（用 microtime(true) 包裹 new PDO() 测），以及你的业务是否能容忍连接状态不可控带来的偶发异常——这比性能数字更难测试，也更容易在线上静默爆发。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
