PolarDB支援會話級串連池和事務級串連池，您可以根據業務情境選擇合適的串連池，協助降低因大量串連導致的資料庫負載壓力。
注意事項
更改串連池設定後，僅對建立串連生效。如何修改串連池設定，請參見設定資料庫代理。
當前串連池功能不支援同一個帳號對不同IP有不同的許可權。如果您為同一個帳號的不同IP設定了不同的庫或者表許可權，開通串連池可能會導致許可權錯誤問題。例如，
user@192.xx.xx.1設定了database_a的許可權，而user@192.xx.xx.2沒有database_a的許可權，可能會導致串連複用時許可權出錯。如果業務頻繁使用
COM_STATISTICS命令時，不建議啟用串連池功能。該命令在資料庫上的實現是先進行上鎖，然後再遍曆所有串連。而開啟串連池功能是將短串連轉變為長串連，這可能會導致長串連的數量增加，從而觸發該命令的瓶頸，進而導致效能下降。同時建議非必要情況下，盡量減少對該命令的調用，頻繁調用會造成嚴重的效能下降，進而影響整體業務的回應時間。本文介紹的功能是PolarDB資料庫代理的串連池功能。該功能並不影響用戶端的串連池功能，如果用戶端已經支援串連池，則可以不使用PolarDB資料庫代理的串連池功能。
會話級串連池
工作原理
會話級串連池用於減少短串連業務頻繁建立新串連導致MySQL負載高。當您的串連斷開時，系統會判斷當前的串連是否是一個閑置的串連，如果是閑置串連，系統將會代理該串連並保留在串連池中一小段時間，如果這時新的串連建立的話就會直接從串連池裡獲得串連（命中的條件包括
user、clientip和dbname等），從而減少與資料庫的建連開銷。如果沒有可用的串連，則走正常串連流程，重新與資料庫建立一個新的串連。使用限制
會話級串連池並不能減少資料庫的並發串連數。該最佳化只能通過降低應用與資料庫的建連速率來減少MySQL主線程的開銷，從而更好地處理業務請求，但是串連池裡閒置串連會短暫占您的串連數。
會話級串連池也不能解決由於存在大量慢SQL，導致的串連堆積問題，此類問題的核心是先解決慢SQL問題。
事務級串連池
工作原理
事務級串連池主要用於減少直接連接到資料庫的Business Connectivity數，以及減少短串連情境下頻繁建連帶來的負載。
開啟事務級串連池後，用戶端與PolarDB代理間可以存在上千個串連，但代理與後端資料庫間可能只存在幾十或幾百個串連。
PolarDB代理本身並沒有最大串連數的限制，串連數的限制主要由後端資料庫中計算節點的規格決定。未開啟事務級串連池時，每條由用戶端發起的串連都需要在後端主節點和所有隻讀節點上各建立一個對應的串連。
開啟事務級串連池後，當用戶端發送請求時，會先與PolarDB代理建連，代理不會馬上將其與後端資料庫建連，而是先從事務級串連池裡尋找是否存在可用的串連（判斷是否為可用串連的條件：
user、dbname和系統變數這3個參數值是否一致）。若不存在，代理會與資料庫建立一個新串連；若存在，則從串連池裡直接拿出並使用，並在當前事務結束後將該串連放回事務級串連池，方便下個請求繼續使用。使用限制如下：
當執行以下行為時，鎖定串連，直至串連結束，即該串連不會再被放到串連池裡供其它使用者串連使用。
執行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()。支援在
INSERT後直接使用SELECT LAST_INSERT_ID()語句，來保證查詢結果正確性。
對於設定了
wait_timeout的串連，wait_timeout在用戶端的表現可能不會生效。因為每次請求都會從串連池中擷取串連，當wait_timeout逾時後，只有串連池中的後端串連會斷開，而後端串連斷開並不會導致用戶端串連斷開。除了
sql_mode、character_set_server、collation_server、time_zone這四個變數以外，如果業務依賴其他會話層級的系統變數，那麼需要用戶端在建連之後顯式進行SET語句執行，否則串連池可能會複用系統變數已經被更改過的串連。由於串連可能會被複用，所以使用
select connection_id()查詢當前串連的thread id可能會變化。由於串連可能會被複用，所以
show processlist或者SQL洞察中顯示的IP地址和連接埠，可能會與用戶端實際的IP地址和連接埠不一致。資料庫代理會將所有節點上的SHOW PROCESSLIST結果合并後再返回最終結果，而在事務級串連池開啟後，前端串連和後端串連的
thread id無法對應。這導致執行KILL命令時可能會返回錯誤：ERROR 1094 (HY000): Unknown thread id：xxx。
串連池的選擇
您可以根據如下建議評估選擇是否開啟串連池以及開啟何種類型的串連池：
若業務使用的多為長串連且串連數較少，或者業務本身已具備較好的串連池，那麼您可以不使用PolarDB的串連池功能。
若業務使用的串連數較多（如串連數需求上萬）或使用的是Serverless服務（即串連數會隨著業務端伺服器的擴容而線性增加），且確認您的業務不涉及上述事務級串連池使用限制的情境，那麼您可以選擇開啟事務級串連池。
若業務使用的純短串連，且業務使用情境中包含上述事務級串連池使用限制的情境，那麼您可以考慮開啟會話級串連池。