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

thread_pool_dedicated_listeners：在每個線程群組中指定一個監聽器線程，以監聽指派給該群組的連線所傳入的陳述式。

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

thread_pool_longrun_trx_limit：在使用所有 thread_pool_max_transactions_limit 的線程執行後，在暫停群組的限制之前要等待多久。

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 表格的語句，除非啟用 autocommit，否則執行緒池會優先處理 InnoDB 的語句，而不是 MyISAM 的語句。啟用 autocommit 時，所有語句都具有低優先順序。

當執行緒群組選取排隊的語句來執行時，它會先查看高優先順序佇列，然後查看低優先順序佇列。如果找到語句，它會從其佇列中移除，並開始執行。

如果語句在低優先順序佇列中停留太久，執行緒池會將其移至高優先順序佇列。thread_pool_prio_kickup_timer 系統變數的值控制移動前的時間。對於每個執行緒群組，每 10 毫秒（每秒 100 個）最多會將一個語句從低優先順序佇列移至高優先順序佇列。

執行緒池會重複使用最活躍的執行緒，以獲得更好的 CPU 快取使用率。這是一個小調整，但對效能產生了很大的影響。

當執行緒從使用者連線執行語句時，效能架構檢測會將執行緒活動計入使用者連線。否則，效能架構會將活動計入執行緒池。

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

一個執行緒開始執行語句，然後被封鎖，並將此情況回報給執行緒池。執行緒群組允許另一個執行緒開始執行另一個語句。

一個執行緒開始執行語句，被封鎖，但沒有回報它被封鎖，因為封鎖沒有發生在已使用執行緒池回呼進行檢測的程式碼中。在這種情況下，執行緒對於執行緒群組來說似乎仍在執行。如果封鎖持續的時間長到語句被視為停滯，群組會允許另一個執行緒開始執行另一個語句。

長時間執行的語句。這些語句會導致所有資源僅被少數語句使用，並可能會阻止所有其他語句存取伺服器。

讀取二進位記錄並將其傳送至複本的二進位記錄傾印執行緒。這是一種長時間運行的 “語句”，它會運行很長時間，且不應阻止其他語句執行。

因資料列鎖定、表格鎖定、休眠或任何其他沒有透過 MySQL 伺服器或儲存引擎回報給執行緒池的封鎖活動而封鎖的語句。