InnoDB 使用作業系統執行緒來處理使用者交易的請求。（交易可能會在提交或回滾之前向 InnoDB 發出許多請求。）在具有多核心處理器的現代作業系統和伺服器上，其中內容切換很有效率，大多數工作負載在不限制並行執行緒數量的情況下都能良好執行。

在有助於最小化執行緒之間內容切換的情況下，InnoDB 可以使用許多技術來限制並行執行的作業系統執行緒數量（以及因此同時處理的請求數量）。當 InnoDB 從使用者會話收到新的請求時，如果並行執行的執行緒數量達到預先定義的限制，則新的請求會睡眠一段短時間，然後再試一次。等待鎖定的執行緒不會計入並行執行執行緒的數量。

您可以透過設定組態參數 innodb_thread_concurrency 來限制並行執行緒的數量。一旦執行的執行緒數量達到此限制，額外的執行緒將睡眠一段微秒數（由組態參數 innodb_thread_sleep_delay 設定），然後才被放入佇列。

您可以將組態選項 innodb_adaptive_max_sleep_delay 設定為允許的 innodb_thread_sleep_delay 的最高值，且 InnoDB 會根據目前的執行緒排程活動自動向上或向下調整 innodb_thread_sleep_delay。這種動態調整有助於執行緒排程機制在系統負載較輕時以及接近滿載運作時順暢運作。

innodb_thread_concurrency 的預設值和並行執行緒數量的隱含預設限制在 MySQL 和 InnoDB 的各種版本中已變更。innodb_thread_concurrency 的預設值為 0，因此預設情況下，並行執行的執行緒數量沒有限制。

InnoDB 僅在並行執行緒數量受到限制時才導致執行緒睡眠。當執行緒數量沒有限制時，所有執行緒都均等地爭奪排程。也就是說，如果 innodb_thread_concurrency 為 0，則會忽略 innodb_thread_sleep_delay 的值。

當執行緒數量有限制時 (當 innodb_thread_concurrency > 0)，InnoDB 會減少上下文切換的開銷，允許在執行單一 SQL 語句期間發出的多個請求進入 InnoDB，而不受 innodb_thread_concurrency 設定的限制。由於一個 SQL 語句 (例如 join) 可能包含 InnoDB 內的多個資料列操作，InnoDB 會分配特定數量的「票券」，允許一個執行緒被重複排程，且開銷最小。

當新的 SQL 語句開始時，執行緒沒有票券，並且必須遵守 innodb_thread_concurrency 的限制。一旦執行緒有權進入 InnoDB，它會被分配一些票券，以便後續進入 InnoDB 執行資料列操作。如果票券用完，執行緒將被逐出，並再次遵守 innodb_thread_concurrency 的限制，這可能會將執行緒放回等待執行緒的先進先出佇列中。當執行緒再次有權進入 InnoDB 時，會再次分配票券。分配的票券數量由全域選項 innodb_concurrency_tickets 指定，預設值為 5000。等待鎖定的執行緒在鎖定可用時會獲得一張票券。

這些變數的正確值取決於您的環境和工作負載。請嘗試不同的值範圍，以確定適合您應用程式的值。在限制同時執行的執行緒數量之前，請查看可能改善多核心和多處理器電腦上 InnoDB 效能的配置選項，例如 innodb_adaptive_hash_index。

有關 MySQL 執行緒處理的一般效能資訊，請參閱第 7.1.12.1 節， 「連線介面」。