在过去的几周里，我们已经达到了MySQL的连接数限制1500次。突然之间Threads_connected刚刚爆炸（短短几分钟内就会出现300 - > 1500）。在PHP中从持久连接切换到非持久连接：我能期待什么？
我们的前端服务器（3次）使用永久连接来连接到数据库服务器（1X）。即使在线程耗尽的情况下，我们的数据库服务器似乎在资源方面做得很好（CPU，内存，IO）。
我想在我们的应用程序（CakePHP的）从持久切换到非持久性连接。我能期待什么？
这样做是一个好主意，还是应该增加连接限制更多？
由于数据库和应用服务器都在不同的机器，你可以在最起码预计脚本执行的延迟增加，由于打开一个新的连接。如果两台服务器都位于局域网内，则可能忽略不计。
显然附加任务将创建额外的负载，但我敢说这也将是几乎无法察觉。打开一个连接与处理查询或其他脚本所做的任何事情相比，只是一小部分开销。
现在，到了真正的问题。正如米奇所说，你可能想调查问题的原因。如果使用持久连接，则每个Web服务器线程都可以打开并维护一个数据库连接。如果负载只有很小的峰值，这可以大大增加连接数量。这个问题对于持久连接和非持久连接来说确实是一样的，除非非持久连接将在事后消失，并且不会由于不必要地占用内存而减慢将来的操作。
一般来说，你必须确保您的网络服务器接受的并发连接，如果你想保证每一个数据库连接成功MySQL服务器可以处理尽可能多的连接。但是，在真实世界的设置中，您的Web服务器很可能会为与数据库无关的连接提供服务。 （图像，CSS，JavaScript等）。考虑到这一点，您可以提供比数据库连接更多的Web服务线程，但有一个问题，这也可能是问题的根源：
如果有人以不同方式访问您网站上的大量网页比在正常使用模式下预期的要高，上述规则不适用。例如，如果搜索引擎抓取您的网站。它们不像浏览器那样按照相同的顺序处理内容。他们可以专注于您的PHP页面，打破了每个客户端都会加载混合数据的假设。如果这是一个问题，取决于您与普通用户数量的比较。如果数据库服务器在高负载下速度变慢，则延迟其他连接的处理，这种影响也可能是累积的。
因此，有意义的是不使用持久连接并管理数据库服务器上的内存，以便可以支持以最大连接数为代价的文件高速缓存和缓冲区，但返回到正常（更快）操作一旦结束，操作就会结束。
P.S .:确保您了解在使用所有连接时数据库将真正使用多少内存。http://www.mysqlperformanceblog.com/2006/05/17/mysql-server-memory-usage/。不要只是增加允许的连接数量，但不要确保具有所需的内存。最好有几次失败的连接尝试，而不是数据库服务器停止工作，因为它的缓冲区已被换出。
您应该关闭PHP中的持续连接，它们不会像您期望的那样工作。你实际上最终会拥有更多的开放空闲连接，而不是不使用它们。手册中的警告实际上警告说连接不足。 http://php.net/manual/en/function.mysql-pconnect.php
你也应该阅读： http://www.php.net/manual/en/features.persistent-connections.php
底线是，永久连接并没有得到重用，他们应该的样子。您看到的尖峰可能是一个僵尸爬行您的网站，并为每个页面负载建立一个新的连接。
您可以预计您的连接问题耗尽将消失。如果Web服务器和数据库服务器之间的网络连接快速可靠，则始终建立新连接的时间和负载将不会很明显。在这方面MySQL实际上非常高效。
我调查为什么你正在使用并解决它连接的爆炸。如果您增加连接数量，您只是通过声音推迟问题。数据库服务器没问题，因为我认为它没有分配超过限制。对您的应用程序有什么影响？ – mikey
@mikey对于某些人来说，应用程序将无法工作，因为它需要数据库连接，但达到限制时无法获得一个... – tersmitten
在这种情况下，增加连接限制只会推迟此问题。也切换到非持久连接也可能只是推迟了这个问题。我会调查为什么连接以这种方式激增，并解决它。 – mikey