ApsaraDB RDS：設定串連池

會話級串連池

應用情境

• 業務側多為短串連

• 串連建立頻繁

以上情境下，業務受到事務級串連池的使用限制而無法使用事務級串連池，可使用會話級串連池。

作用

降低應用與資料庫建立串連的頻率來減少MySQL資料庫主線程的開銷。

工作原理

前端串連與後端串連

在用戶端（應用）與資料庫建立串連時，以資料庫代理為中間節點可將該串連分為前端串連（用戶端與資料庫代理的串連）和後端串連（資料庫代理與資料庫的串連）。如下圖所示。

未開啟串連池時的串連建立過程

未開啟串連池時，每條由用戶端發起的會話都需要建立前端串連和後端串連。會話結束後，前端串連和後端串連均斷開，等到下次用戶端發起會話請求時，再重新建立新的前端串連和後端串連。如下圖所示。

使用這種建立串連的方式，每次會話都要重建立立後端串連，對資料庫的主線程的開銷較大。

會話級串連池工作原理

對於會話級串連池，當用戶端發起的會話建立串連時，先建立前端串連，然後判斷串連池中是否存在可用的後端串連：

• 若存在，則直接使用。

• 若不存在，則與資料庫建立新的後端串連。

會話結束後，前端串連斷開，後端串連放入串連池，待新的會話建立串連時，可直接使用該後端串連。

這樣，就降低了資料庫代理與資料庫建立串連的頻率，從而減少了資料庫主線程的開銷。

串連建立的流程如下圖所示。

對於會話級串連池，一個會話需要佔用一個後端串連，直到會話結束才會釋放後端串連到串連池，如下圖所示。

使用限制

無。

注意事項

對於會話級串連池，在一個會話未結束之前，即便該會話處於閑置狀態，沒有事務需要處理，其後端串連也不能為其他會話使用，所以不能減少資料庫的總串連數。

事務級串連池（推薦）

應用情境

• 業務側多為短串連

• 串連建立頻繁

• 串連數量很大（大於MySQL資料庫的串連數限制）

以上情境下，業務不涉及事務級串連池的使用限制，建議優先選擇事務級串連池。

作用

• 降低應用與資料庫建立串連的頻率來減少MySQL資料庫主線程的開銷。

• 減少資料庫上的總串連數。

工作原理

開啟事務級串連池後，當用戶端發起串連會話請求時，只會先與資料庫代理建立前端串連，代理不會馬上將其與後端資料庫建立串連；當需要處理請求時，從事務級串連池裡尋找是否存在可用的後端串連：

• 若存在，則從串連池裡直接擷取後端並使用，並在當前事務結束後將該串連放回事務級串連池，方便下個請求繼續使用。

• 若不存在，代理會與資料庫建立一個新的後端串連。

對於事務級串連池，在一段時間內，多個會話可共用一個後端串連。如下圖所示，事務活躍的串連會佔用後端串連，事務非活躍的串連不會佔用後端串連。

這樣，在一段時間內，同一個後端串連，就可以處理多個進行中的會話的交易處理請求，可以帶來以下好處：

• 減少與資料庫建立串連的頻率

  後端串連在一段時間內與資料庫並沒有斷開，能夠減少與資料庫建立串連的頻率，從而減少資料庫主線程的開銷。

• 減少與資料庫的總串連數

  多個進行中的會話共用了一個後端串連，避免了閑置串連（會話未結束，但前端串連為非活躍狀態）對後端串連資源的佔用，減少了資料庫上的總串連數。

使用限制

• 執行以下操作時，串連將被鎖定直至串連結束（即該串連不會再被放到串連池裡供其他使用者串連使用）：

  • 執行PREPARE語句或命令。

  • 建立暫存資料表。

  • 修改使用者變數。

  • 大報文（例如16 MB以上）。

  • 使用LOCK TABLE。

  • 多語句。

  • 預存程序調用。

• 不支援FOUND_ROWS、ROW_COUNT和LAST_INSERT_ID函數的調用，這些函數可以調用成功，但是無法保證調用結果的正確性。其中：

  • 1.13.11及以上的資料庫代理版本支援在SELECT SQL_CALC_FOUND_ROWS * FROM t1 LIMIT *語句後直接使用SELECT FOUND_ROWS()命令。但MySQL官方已不推薦該用法，建議您將SELECT FOUND_ROWS()替換為SELECT COUNT(*) FROM tb1進行查詢，詳情請參見FOUND_ROWS()。

  • 1.13.11及以上的資料庫代理版本支援在INSERT後直接使用SELECT LAST_INSERT_ID()語句，來保證查詢結果正確性。

注意事項

• 對於設定了wait_timeout的串連，wait_timeout在用戶端的表現可能不會生效，因為每次請求都會從串連池中擷取串連，當wait_timeout逾時後，只有串連池中的後端串連會斷開，而後端串連斷開並不會導致用戶端串連斷開。

• 除了sql_mode、character_set_server、collation_server、time_zone這四個變數以外，如果業務依賴其他session層級的系統變數，那麼需要用戶端在建連之後顯式執行set語句，否則串連池可能會複用系統變數已經被更改過的串連。

• 由於串連可能會被複用，您可以使用select connection_id()查詢當前串連的thread id。

• 由於串連可能會被複用，所以show processlist或者SQL洞察顯示的IP地址和連接埠可能和用戶端實際的IP地址和連接埠不一致。

• 資料庫代理會將所有節點上的show processlist結果合并後返回，在事務級串連池開啟後，前端串連和後端串連的thread id無法對應。這導致kill命令可能會報錯，但是實際上kill命令已經正常執行成功，可再通過show processlist確定相應的串連是否斷開。