Mysql連接池問題：值得嗎？

Question

我記得聽說mysql中的連接過程與其他RDBMS相比設計得非常快，因此如果啟用連接池，那么使用提供連接池 （SQLAlchemy） 的庫實際上不會對您有太大幫助。

有人對這個有經驗么？

我很樂意啟用它，因為如果某些代碼對數據庫連接做了某些有狀態的事情並且（可能是錯誤地）不會自行清理，那么在關閉連接時通常會被清理的狀態將改為傳播到后續代碼，獲得循環連接。

Answer 1

使用SQLA的連接池時，無需擔心連接上的剩余狀態，除非您的應用程序正在更改連接范圍的選項，如事務隔離級別（通常情況並非如此）。 簽入時，SQLA的連接池在連接上發出connection.rollback（），以便清除任何事務狀態或鎖。

MySQL的連接時間可能非常快，特別是如果你在同一台機器上連接unix套接字。 如果您確實使用了連接池，那么您還需要確保在一段時間后回收連接，因為MySQL的客戶端庫將自動關閉空閑超過8小時的連接（在SQLAlchemy中這是pool_recycle選項）。

通過將池實現從默認的QueuePool更改為NullPool，您可以快速完成連接池與非SQLA應用程序的連接，NullPool是一個實際上不會集合任何內容的池實現 - 它連接和斷開連接時為真實的獲取代理連接，然后關閉。

Answer 2

即使MySQL本身的連接部分非常光滑，也可能存在涉及的網絡連接（無論是環回還是物理連接）。 如果你提出了很多要求，那么這可能會非常昂貴。 它取決於（通常情況下）你的應用程序究竟在做什么，當然 - 如果你在每個連接上做了很多工作，那么這將占主導地位並且你不會獲得很多。

如果有疑問，那么基准測試 - 但我總體上相信連接池庫（至少是一個有信譽的庫）應該正常工作並適當地重置事物。

Answer 3

簡短的回答：你需要對它進行基准測試。

答案很長：這取決於。 MySQL快速進行連接設置，因此避免這種成本並不是連接池的好理由。 你贏了的地方就是如果查詢運行很少而且速度很快，因為那樣你就會看到一個帶池的勝利。

另一個擔心是應用程序如何處理SQL線程。 如果它沒有SQL事務，並且不對線程的狀態做出任何假設，那么池化將不會成為問題。 OTOH，依賴於關閉線程來丟棄臨時表或回滾事務的代碼在池化時會遇到很多問題。

Answer 4

連接池可以加快速度，因為每次執行數據庫查詢時都沒有創建java.sql.Connection對象。 我將Tomcat連接池用於mysql數據庫，用於執行大量查詢的Web應用程序，在高用戶負載期間，速度明顯提高。

Answer 5

我用Django做了一個簡單的RESTful服務，並在有和沒有連接池的情況下對它進行了測試。 就我而言，差異非常明顯。

在局域網中，沒有它，響應時間在1到5秒之間。 有了它，不到20毫秒。 結果可能會有所不同，但我用於MySQL和Apache服務器的配置是非常標准的低端。

如果您通過互聯網提供UI頁面，則用戶可能無法注意到額外的時間，但在我的情況下，這是不可接受的，因此我選擇使用該池。 希望這對你有所幫助。