MySQL-單連接與池

Question

由於我已經回答了一些有關MySQL同步特性的先前問題，因此我開始質疑人們使用連接池的原因，如果在我的情況下，我應該移至一個池。

當前，我的應用程序保持單個連接處於活動狀態。 在我的應用程序中，只有一個connection, statement, and result set可以循環使用。 我所有的數據庫任務都放在隊列中，並在單獨的線程上背靠背執行。 一個線程用於數據庫查詢，一個連接用於數據庫訪問 。 如果連接出現問題，它將處理該連接並創建一個新的連接。

根據我的理解，無論有多少查詢發送到MySQL進行處理，都將按照接收順序對它們進行同步處理。 這些查詢是來自單個還是多個查詢都沒有關系，它們將按接收到的順序執行。

如此說來，無論是否要一一處理它們，具有多個連接和線程將查詢粉碎到數據庫的處理隊列的意義何在？ 在查詢未完成處理之前，該查詢將不會執行，同樣，在我不使用池的情況下，下一個查詢也不會執行，直到前一個查詢已完成處理。

現在您可能會說：

處理MySQL查詢提供的結果所花費的時間將增加兩次執行查詢之間的時間。

顯然，這是正確的，這就是為什么我有一個處理查詢結果的工作線程的原因。 查詢完成后，我將結果轉換為Map<>格式，並從內存中釋放語句/結果集，並開始處理下一個查詢。 Map<>被發送到單獨的Worker線程進行處理，因此它不會阻塞查詢執行線程。

誰能告訴我我做事的方式是否正確，是否應該花時間轉移到連接池而不是持久連接。 最重要的是為什么。 我嚴格出於參考目的啟動此線程。

編輯：2016/4/29

我想補充一點，我知道連接池是什么，但是當表在查詢處理開始時鎖定所有連接的請求時，我更好奇在單個持久連接上使用池的好處。

Answer 1

只是嘗試這個StackOverflow的東西，但是，

在大多數情況下，在與數據庫的每次連接中，它都是空閑的。 當您在對表的INSERT或UPDATE連接中執行查詢時，它會鎖定該表，從而防止並發編輯。 盡管這一切都很好，但可以防止數據覆蓋或損壞，這意味着在第一個連接/查詢仍在運行時，沒有其他連接可以進行編輯。

但是，開始新的連接需要時間，並且在大型基礎架構中試圖掠過所有多余時間，這是不好的。 因此，連接池是處於空閑狀態的整組連接，准備下一次查詢。

最后，如果您正在運行一個小型項目，通常沒有理由使用連接池，但是如果您正在運行一個大型站點且UPDATE和INSERT大約每毫秒運行一次，則連接池會減少開銷時間。

Answer 2

答案略相關 ：池可以執行其他“連接運行狀況檢查”（通過檢查SQL異常代碼）並刷新連接以減少內存使用（請參見答案中有關“ maxLifeTime”的注釋）。 但是所有這些事情可能不會超過使用一種連接的簡單方法。

要考慮的另一個因素是（阻塞）網絡I / O時間。 考慮以下（粗略）情況：

client prepares query --> client sends data over the network
--> server receives data from the network --> server executes query, prepares results
--> server sends data over the network --> client receives data from the network
--> client prepares resultset

如果數據庫是本地的（與客戶端在同一台計算機上），則網絡時間幾乎不會引起注意。 但是，如果數據庫是遠程的，則網絡I / O時間可以衡量並影響性能。 假設隔離級別處於“已讀提交”狀態，則並行運行選擇語句可能會變得更快。 根據我的經驗，同時使用4個連接而不是1個連接通常可以提高性能（或吞吐量）。 這確實取決於您的特定情況：如果MySQL實際上實際上只是在等待鎖被釋放，那么就速度而言，添加其他連接不會有多大作用。 同樣，如果客戶端是單線程的，則客戶端實際上可能不會感覺到任何明顯的速度改進。

不過，這應該足夠容易地進行測試：使用1個連接比較一個程序與1個線程的執行時間，以與另一個程序使用4個線程執行X數量的選擇查詢（即重用當前程序），每個線程使用1個單獨的連接，以執行相同的X數量的選擇查詢，除以4個線程（或僅將第一個程序並行運行4次）。

關於連接池（如HikariCP ）的一個注釋：連接池返回連接池時，池必須確保沒有事務保持打開狀態，這可能意味着每次將連接返回至池（關閉）時都會發送“回滾”自動提交功能已關閉，之前未發送過任何“提交”或“回滾”消息。 反過來，這可以增加而不是減少網絡I / O時間。 因此，請確保在啟用自動提交的情況下進行測試，或者確保在完成查詢或一組查詢后始終發送提交或回滾。

Answer 3

連接池和持久連接不是一回事。 一個是SQL連接數的限制，另一個是單管道問題。 問題通常是將SQL輸出傳輸到服務器所花費的時間比查詢執行時間要長。 因此，如果您打開兩個cli SQL客戶端並觸發兩個查詢，一個查詢具有較大的輸出，而另一個查詢具有較小的輸出（按此順序），則較小的一個首先完成，而較大的一個仍在滾動其輸出。 這里的要點是多重連接確實可以解決上述情況下的問題。

當您有多個前端請求進行查詢時，您可能更喜歡持久連接，因為它為您帶來了多於不同連接（大型輸出與小型輸出）進行復用的好處，並避免了會話建立/拆卸的開銷。

連接池API具有內置的錯誤檢查和處理功能，但是大多數API仍然希望您手動聲明是否需要持久連接。

因此，實際上，通過API有3個變量，池，持久性和配置參數。 必須混合使用池大小，持久性和與套房環境的連接數進行匹配