Php 在 PDO 中使用持久连接有什么缺点

请务必阅读this answer below，其中详细介绍了缓解此处列出的问题的方法.

使用PDO和任何其他PHP数据库接口都存在同样的缺点，这些接口会进行持久连接:如果脚本在数据库操作的中间意外终止，则获得左连接的下一个请求将在死脚本中被删除.连接在进程管理器级别保持打开状态(Apache for mod_php，如果使用FastCGI，则为当前的FastCGI进程，等等)，而不是在php级别，并且当脚本异常终止时，php不会告诉父进程让连接终止.

如果死脚本锁定了表，则这些表将保持锁定状态，直到连接终止，或者获得连接的下一个脚本解锁表本身.

如果死脚本在事务中间，那么在死锁计时器开始工作之前，可能会关闭大量的表，即使在那时，死锁计时器也会终止较新的请求，而不是导致问题的较旧的请求.

如果死脚本处于事务中间，则获得该连接的下一个脚本也会获得事务状态.很有可能(取决于您的应用程序设计)，下一个脚本可能不会实际try 提交现有事务，或者在不应该提交时提交，或者在不应该提交时回滚.

这只是冰山一角.通过始终try 在每个脚本请求的脏连接之后进行清理，可以在一定程度上缓解这一问题，但根据数据库的不同，这可能是一种痛苦.除非您在脚本中将创建数据库连接标识为the one thing that is a bottleneck(这意味着您已经使用xdebug和/或xhprof进行了代码分析)，否则not应该考虑将持久连接作为任何问题的解决方案.

此外，大多数现代数据库(包括PostgreSQL)都有自己喜欢的执行连接池的方法，这些方法没有普通的基于PHP的持久连接所具有的直接缺点.

为了澄清一点，我们在我的工作场所使用持久联系，但不是自愿的.我们遇到了weird个连接行为，从我们的应用程序服务器到数据库服务器的初始连接花费了exactly 3秒，而实际上应该只需要零点几秒.我们认为这是一个内核错误.我们放弃了排除故障的try ，因为它是随机发生的，不能按需复制，我们外包的IT部门也没有具体的能力来追踪它.

不管怎样，当仓库里的人在处理几百个来料零件时，每个零件都需要3.5秒而不是1.5秒，我们必须在他们绑架我们并让我们帮助他们之前采取行动.因此，我们在自己开发的ERP/CRM/CMS怪兽中翻了几页，亲身体验了持久连接的所有恐怖.我们花了weeks美元才找到所有看似随机发生的微妙小问题和奇怪行为.事实证明，那些每周一次的致命错误是我们的用户努力从我们的应用程序中挤出的，它们留下了锁定的表、放弃的事务和其他不幸的不稳定状态.

这个悲伤的故事有一个道理:It broke things that we never expected to break, all in the name of performance.这个权衡是不值得的，我们Eager 地等待着有一天我们可以切换回正常的连接，而不会引起用户的骚动.