thread_pool_algorithm：用於排程的並行演算法。

thread_pool_dedicated_listeners：在每個執行緒群組中專門設定一個監聽執行緒，以監聽指派給該群組的連線所傳入的陳述式。

thread_pool_high_priority_connection：如何排程工作階段的陳述式執行。

thread_pool_max_active_query_threads：每個群組允許多少個活動執行緒。

thread_pool_max_transactions_limit：線程池外掛程式允許的最大交易數。

thread_pool_max_unused_threads：允許多少個休眠執行緒。

thread_pool_prio_kickup_timer：線程池將等待執行的陳述式從低優先順序佇列移至高優先順序佇列之前等待的時間長度。

thread_pool_query_threads_per_group：一個執行緒群組中允許的查詢執行緒數量（預設為單個查詢執行緒）。如果您因長時間執行的交易而遇到較慢的回應時間，請考慮增加該值。

thread_pool_size：線程池中的執行緒群組數量。這是控制線程池效能最重要的參數。

thread_pool_stall_limit：執行中的陳述式被視為停頓之前的時間長度。

thread_pool_transaction_delay：開始新交易之前的延遲時間。

每個執行緒群組都有一個監聽執行緒，用於監聽從分配給該群組的連線傳入的陳述式。當陳述式到達時，執行緒群組會立即開始執行它，或將其排入佇列以供稍後執行。

thread_pool_transaction_delay 變數指定交易延遲的毫秒數。工作執行緒會在執行新交易之前休眠指定的期間。

當平行交易由於資源爭用而影響其他作業的效能時，可以使用交易延遲。例如，如果平行交易影響索引建立或線上緩衝池調整大小操作，您可以設定交易延遲，以減少這些操作執行時的資源爭用。延遲會對交易產生節流效果。

thread_pool_transaction_delay 設定不會影響從特權連線（分配給 Admin 執行緒群組的連線）發出的查詢。這些查詢不受設定的交易延遲的影響。

如果發生立即執行，則由監聽執行緒執行。（這表示該群組中暫時沒有執行緒在監聽。）如果陳述式快速完成，則執行執行緒會返回監聽陳述式。否則，執行緒集區會將陳述式視為停滯，並啟動另一個執行緒作為監聽執行緒（如有必要，則會建立它）。為了確保沒有執行緒群組因停滯的陳述式而遭到封鎖，執行緒集區會有一個背景執行緒定期監控執行緒群組狀態。

透過使用監聽執行緒來執行可以立即開始執行的陳述式，如果陳述式快速完成，則無需建立其他執行緒。這可確保在並行執行緒數量較少的情況下，盡可能有效率地執行。

當執行緒集區外掛程式啟動時，它會為每個群組建立一個執行緒（監聽執行緒），加上背景執行緒。如有必要，會建立其他執行緒來執行陳述式。

thread_pool_stall_limit 系統變數的值決定了前一個項目中 「快速完成」 的含義。預設的執行緒被視為停滯前的時間為 60 毫秒，但可以設定為最多 6 秒。此參數可配置，讓您可以達到適合伺服器工作負載的平衡。較短的等待時間可讓執行緒更快啟動。較短的值也更適合避免死鎖情況。較長的等待時間對於包含長時間執行陳述式的工作負載很有用，可避免在執行當前陳述式時啟動過多的新陳述式。

如果 thread_pool_max_active_query_threads 為 0，則應用如上所述的預設演算法來決定每個群組的最大活動執行緒數量。預設演算法會將停滯的執行緒納入考量，並可能暫時允許更多活動執行緒。如果 thread_pool_max_active_query_threads 大於 0，則會限制每個群組的活動執行緒數量。

執行緒集區的重點在於限制同時執行的短執行陳述式的數量。在執行中的陳述式達到停滯時間之前，它會阻止其他陳述式開始執行。如果陳述式執行超過停滯時間，則允許它繼續執行，但不再阻止其他陳述式開始執行。透過這種方式，執行緒集區會嘗試確保每個執行緒群組中永遠不會有一個以上的短執行陳述式，儘管可能有多個長時間執行的陳述式。不宜讓長時間執行的陳述式阻止其他陳述式執行，因為可能需要等待的時間沒有限制。例如，在複寫來源伺服器上，將二進位日誌事件傳送至複本的執行緒實際上會永久執行。

如果陳述式遇到磁碟 I/O 作業或使用者層級鎖定（資料列鎖定或資料表鎖定），則陳述式會遭到封鎖。封鎖會導致執行緒群組變成未使用，因此會回呼執行緒集區，以確保執行緒集區可以立即在此群組中啟動新的執行緒來執行另一個陳述式。當遭到封鎖的執行緒返回時，執行緒集區會允許它立即重新啟動。

有兩個佇列，一個高優先權佇列和一個低優先權佇列。交易中的第一個陳述式會進入低優先權佇列。如果交易正在進行（已開始執行其陳述式），則交易的任何後續陳述式都會進入高優先權佇列，否則會進入低優先權佇列。佇列指派可能會受到啟用 thread_pool_high_priority_connection 系統變數的影響，這會導致工作階段的所有排隊陳述式都進入高優先權佇列。

如果啟用 autocommit，則非交易儲存引擎的陳述式或交易引擎的陳述式會被視為低優先權陳述式，因為在這種情況下，每個陳述式都是一個交易。因此，如果同時有 InnoDB 和 MyISAM 資料表的陳述式，則執行緒集區會優先處理 InnoDB 的陳述式，而非 MyISAM 的陳述式，除非啟用 autocommit。啟用 autocommit 後，所有陳述式都具有低優先權。

當執行緒群組選擇一個排隊的陳述式執行時，它會先在高優先權佇列中尋找，然後在低優先權佇列中尋找。如果找到陳述式，則會將其從佇列中移除並開始執行。

如果陳述式在低優先權佇列中停留過久，執行緒集區會移至高優先權佇列。thread_pool_prio_kickup_timer 系統變數的值會控制移動前的時間。對於每個執行緒群組，每 10 毫秒（每秒 100 個）最多會將一個陳述式從低優先權佇列移至高優先權佇列。

執行緒集區會重複使用最活躍的執行緒，以大幅提升 CPU 快取的利用率。這是一個小的調整，但對效能有很大的影響。

當執行緒執行來自使用者連線的陳述式時，效能結構描述檢測會將執行緒活動歸因於使用者連線。否則，效能結構描述會將活動歸因於執行緒集區。

一個執行緒開始執行陳述式，但執行時間長到被視為停滯。即使第一個執行緒仍在執行，執行緒群組也允許另一個執行緒開始執行另一個陳述式。

一個執行緒開始執行陳述式，然後遭到封鎖並將此情況回報給執行緒集區。執行緒群組允許另一個執行緒開始執行另一個陳述式。

一個執行緒開始執行陳述式，遭到封鎖，但未回報其已遭到封鎖，因為封鎖並未發生在已使用執行緒集區回呼檢測的程式碼中。在這種情況下，執行緒對執行緒群組而言似乎仍在執行。如果封鎖持續的時間長到足以讓陳述式被視為停滯，則群組會允許另一個執行緒開始執行另一個陳述式。

長時間執行的陳述式。這會導致所有資源僅由少數幾個陳述式使用，並可能阻止所有其他陳述式存取伺服器。

讀取二進位日誌並將其傳送至複本的二進位日誌傾印執行緒。這是一種長時間執行的 「陳述式」，它會執行很長時間，並且不應阻止其他陳述式執行。

遭到資料列鎖定、資料表鎖定、睡眠或任何其他未由 MySQL 伺服器或儲存引擎回報給執行緒集區的封鎖活動所封鎖的陳述式。