我記得聽說mysql中的連接過程與其他RDBMS相比非常快，因此如果啓用連接池，那麼使用a library that provides connection pooling（SQLAlchemy）實際上不會對您有太大的幫助。Mysql連接池問題：值得嗎？
有沒有人有這方面的經驗？
我不願意啓用它，因爲如果某些代碼對db連接執行某些有狀態並且（可能錯誤地）不會自行清理之後，通常會在關閉後清除該狀態連接將反而被傳播到後續的獲得回收連接的代碼。
使用SQLA的連接池時，不需要擔心連接上的剩餘狀態，除非應用程序正在更改連接範圍的選項，如事務隔離級別（通常情況並非如此）。 SQLA的連接池在重新檢入時在連接上發出connection.rollback（），以便清除任何事務狀態或鎖。
MySQL的連接時間可能非常快，特別是如果您通過同一臺機器上的unix套接字進行連接。如果您使用連接池，則還需要確保連接在一段時間後回收，因爲MySQL的客戶端庫會自動關閉空閒時間超過8小時的連接（在SQLAlchemy中，這是pool_recycle選項）。
通過將池實現從QueuePool更改爲NullPool，這是一個池實現，它實際上並沒有集合任何東西 - 它連接和斷開連接，您可以快速完成連接池與非SQLA應用程序的一些連接當代理連接被獲取並且隨後關閉時爲真實的。
即使MySQL本身的連接部分非常漂亮，可能仍然存在網絡連接（無論是環回還是物理連接）。如果您正在製作批次的請求，那可能會非常昂貴。它將取決於（通常情況下）確切地說你的應用程序做了什麼，當然 - 如果你在每個連接上做了很多工作，那麼這將佔主導地位，你不會獲得很多。
如果有疑問，基準測試 - 但我會大致相信連接池庫（至少是有聲望的）應該能正常工作並適當地重新設置。
連接池加快了速度，因爲每次執行數據庫查詢時都沒有創建java.sql.Connection對象。我使用Tomcat連接池爲mysql數據庫提供了大量查詢的web應用程序，在高用戶負載期間，速度有了明顯的改善。
這個問題適用於python，不適用於Java。 – 2014-02-24 18:01:32
簡答：您需要對其進行基準測試。
長答案：這取決於。 MySQL的連接建立速度很快，所以避免這種成本並不是連接池的好理由。如果你贏了，那麼如果查詢運行的很少，而且速度很快，那麼你會看到一個共享的勝利。
另一個問題是應用程序如何處理SQL線程。如果它沒有執行SQL事務，並且不對線程的狀態做任何假設，那麼池化不會是一個問題。 OTOH，依賴關閉線程來放棄臨時表或回滾事務的代碼在集成時會遇到很多問題。
我用Django製作了一個簡單的RESTful服務，並在連接池和不連接池的情況下對它進行了測試。在我的情況下，差異非常明顯。
在局域網，沒有它，響應時間爲1秒和5秒之間。有了它，少於20毫秒。 結果可以改變，但我使用爲MySQL &的Apache服務器的配置是非常標準的低端。
如果你的服務在互聯網上UI頁面額外的時間可能不太明顯給用戶，但對我來說這是不能接受的，所以我選擇了使用泳池。希望這可以幫助你。
我發現這表明阿帕奇百科全書數據庫連接池是壞的另一個問題/計算器上的評論。 – the0ther 2009-10-16 19:01:11