在過去的幾周裏，我們已經達到了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