请务必阅读以下答案，其中详细介绍了缓解此处概述的问题的方法。
使用PDO与进行持久连接的任何其他PHP数据库接口一样，也存在相同的缺点：如果您的脚本在数据库操作过程中意外终止，则下一个获得剩余连接的请求将在死脚本停止的地方接管。连接在进程管理器级别（Apache for mod_PHP，如果使用的是FastCGI，则为当前的FastCGI进程，等等）保持打开状态，而不是在PHP级别保持打开状态，并且PHP不会告诉父进程何时让连接终止脚本异常终止。
如果死脚本锁定了表，则这些表将保持锁定，直到连接死亡或下一个获得连接的脚本将表本身解锁为止。
如果死脚本位于事务中间，则可以阻塞多个表，直到死锁计时器开始运行为止，即使那样，死锁计时器也可以杀死较新的请求，而不是导致问题的较旧的请求。
如果无效脚本位于事务中间，则下一个获得该连接的脚本也将获得事务状态。下一个脚本很有可能（取决于您的应用程序设计）实际上不尝试提交现有事务，或者在不应该存在时将提交，而在不应该存在时回退。
这只是冰山一角。通过在每个脚本请求上进行肮脏的连接后始终尝试进行清理，可以在一定程度上缓解所有问题，但这取决于数据库，可能会很麻烦。除非你已经确定了创建数据库连接为一两件事，是一个瓶颈 在您的脚本这意味着你所做的代码中使用剖析了XDebug和/或XHProf的，你应该_不_ 考虑作为解决任何持久连接。
此外，大多数现代数据库（包括Postgresql）都有自己喜欢的执行连接池的方式，它们没有直接基于普通PHP的持久性连接所具有的直接缺点。
为了阐明这一点，我们在工作场所使用持久连接，但不是出于选择。我们遇到了 奇怪的 连接行为，从我们的应用程序服务器到数据库服务器的初始连接 正好 花了 三秒钟，而这本来应该只需要几分之一秒。我们认为这是一个内核错误。我们放弃尝试对其进行故障排除，因为它是随机发生的并且无法按需复制，并且我们的外包IT没有具体的能力来对其进行跟踪。
无论如何，当仓库中的人员正在处理几百个进来的零件，并且每个零件要花三分半秒而不是半秒的时间时，我们必须采取行动，然后他们才绑架我们，并要求我们帮助他们。因此，我们在自己的ERP / CRM / CMS怪诞中花了些力气，并亲身经历了所有持久连接的恐怖。我们花了 几周的时间 来追踪所有看似随机发生的细微问题和奇怪行为。事实证明，我们的用户孜孜不倦地挤出应用程序的那些每周一次的致命错误正在离开锁定表，放弃交易和其他不幸的不稳定状态。
602392714
清零编程群