MySQL InnoDB配置併發線程（ innodb_thread_concurrency）

http://www.ywnds.com/?p=9821

1、thread_concurrency

首先，最重要的一點，這個參數已經在最新版本的MySQL中被移除了，官方最新5.7版本的doc上面對thread_concurrency有這樣的說明：

thread_concurrency變量是針對於Solaris 8及低版本的系統，設置了這個變量MySQL會調用thr_setconcurrency()函數。這個函數容許應用程序給同一時間運行的線程系統提示所需數量的線程。當前的Solaris版本中這個參數已經沒有做用了，這個參數在MySQL 5.6.1中已經被標記爲過期，在5.7.2版本的MySQL中被移除。

2、innodb_thread_concurrency參數介紹

MySQL的兩種存儲引擎：MyISAM和InnoDB，InnoDB支持事務，也是MySQL默認的存儲引擎，在InnoDB中，咱們能夠經過設置參數innodb_thread_concurrency限制線程的數量。

先來看一下官方Configuring Thread Concurrency for InnoDB對innodb_thread_concurrency參數的配置說明，翻譯以下：

InnoDB使用操做系統線程來處理用戶的事務請求。（在事務提交或回滾以前可能給InnoDB引擎帶來不少的請求）。在現代化操做系統和多核處理器的服務器上，上下文切換是很是高效的，大多數工做負載運行沒有任何併發線程數量的限制。在MySQL 5.5及以上版本中，MySQL作了可伸縮性的改進，它減小了這種在InnoDB內部限制併發執行線程數量的須要。

它有助於在最小化的狀況下進行線程之間的上下文切換，InnoDB可使用各類技術來限制操做系統併發執行線程的數量（所以大批量的請求能夠在任何一個時間獲得處理）。當InnoDB從用戶會話收到一個新的請求，若是線程併發執行的數量達到預約義的限制，那麼新的請求會先睡眠一段時間後再次嘗試。在睡眠後不能按計劃執行的請求會被放入先入/先出隊列，並最終處理。但那些等待獲取鎖的線程則不會被計入到併發執行線程的數量中。 咱們能夠經過設置配置參數innodb_thread_concurrency來限制併發線程的數量，一旦執行線程的數量達到這個限制，額外的線程在被放置到對隊列中以前，會睡眠數微秒，能夠經過設定參數innodb_thread_sleep_delay來配置睡眠時間。

在MySQL 5.6.3以前的版本中，MySQL要求經過測試和實驗找到innodb_thread_sleep_delay的最優值，這個最優值可能會因工做負載狀況不一樣而發生改變。在MySQL 5.6.3及更高版本中，你能夠經過設置參數innodb_adaptive_max_sleep_delay爲innodb_thread_sleep_delay設置最大容許的值，InnoDB會根據當前線程調度活動自動調整innodb_thread_sleep_delay的值，這種動態調整機制有助於工做的線程，在系統負載低時或系統接近滿負荷運轉時，都可以順利的調度。

在MySQL和InnoDB以前的版本系列中，innodb_thread_concurrency的默認值，以及其隱含的限制併發線程執行的數量都進行過調整。在當前最新版本的MySQL中，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分配指定數量的 「 tickets 」，容許以最少的開銷重複排列線程。

當一個新的SQL語句開始，當前線程沒有「tickets」時，它就必須遵照innodb_thread_concurrency參數設置，一旦這個線程有權進入InnoDB，它會被分配一個「tickets」，它能夠經過這個「tickets」用於隨後進入InnoDB執行行操做，若是「tickets」使用完畢，該線程將會被驅逐，innodb_thread_concurrency參數會被放回到先入/先出隊列中等待的線程等待再次觀察。一旦這個線程再次有權進入InnoDB，「tickets」又會被從新分配，咱們能夠經過設置全局參數innodb_concurrency_tickets來指定「tickets」的數量，默認狀況下是5000。正在等待獲取鎖的線程，一旦鎖可用，會被當即分配一個「tickets」。

這些參數的正確值取決於當前系統環境和負載狀況。嘗試各類不一樣的值，以肯定哪些值適用於當前應用程序。在限制併發執行的線程數以前，在多核及多處理器的計算機上，檢查一下InnoDB的配置參數是否能夠改善性能，好比innodb_adaptive_hash_index。

3、innodb_thread_concurrency&innodb_thread_sleep_delay&innodb_concurrency_tickets

這三個參數的配合使用就是這樣的一個故事（看網上一個哥們寫的，摘抄下來）

一個屋子內有一個頭牌妓女叫Innodb, 你們都想接近她．

老鴇(MySQL)不可能容許那麼多人同時進屋去，就限制每次只能進去幾個（上下和手嘛．．），這個限制的名字就叫(innodb_thread_concurrency).

其餘的人怎麼辦，只能在外面排成長隊依次進入．同時老鴇說，大爺大家能夠睡一會，這樣就不用苦苦等待了．

這裏老鴇就會個一段時間（innodb_thread_sleep_delay）叫醒一位大爺，以避免睡不醒了．

老鴇也怕老是叫醒大爺很差交代，就看快到了再叫，老鴇本身發明了一個自適應的叫醒算法，可以儘可能減小喚醒次數．

可是大爺會規定一個最長喚醒時間，就是必須在這樣的時間（innodb_adaptive_max_sleep_delay）時喚醒我．

如此當有人從內部出來之後，等待的大爺(排在最前面的)就能夠進入享受魚水之歡了．

可是每位大爺可以支持的時間不同，有的一分鐘（quicker）,有的大爺須要幾個小時．這樣外面等待的大爺就會有意見，哎呀，怎麼還不出來．

老鴇又想了一個辦法，規定每一個人不能在姑娘房裏呆10分鐘以上(innodb_concurrency_tickets), 有特別持久的人就須要在10分鐘時出來，在繼續排隊(排在隊尾)．

等到下一次輪到他再進行魚水之歡．

人物對應：老鴇(MySQL), 大爺(threads), 姑娘(innodb)

如何優化innodb_concurrency_tickets，那就得看哪位大爺重要，好比宰相的兒子在這裏等，那宰相的兒子又十分持久，最好就用多點時間（增大innodb_concurrency_tickets）

若是宰相的兒子不持久，那就用小時間快點排到他。

4、innodb_thread_concurrency使用建議

在官方文檔上，對於innodb_thread_concurrency的使用，也給出了一些建議，以下：

若是一個工做負載中，併發用戶線程的數量小於64，建議設置innodb_thread_concurrency=0；

若是工做負載一直較爲嚴重甚至偶爾達到頂峯，建議先設置innodb_thread_concurrency=128，並經過不斷的下降這個參數，96, 80, 64等等，直到發現可以提供最佳性能的線程數，例如，假設系統一般有40到50個用戶，但按期的數量增長至60，70，甚至200。你會發現，性能在80個併發用戶設置時表現穩定，若是高於這個數，性能反而降低。在這種狀況下，建議設置innodb_thread_concurrency參數爲80，以免影響性能。

若是你不但願InnoDB使用的虛擬CPU數量比用戶線程使用的虛擬CPU更多（好比20個虛擬CPU），建議經過設置innodb_thread_concurrency參數爲這個值（也可能更低，這取決於性能體現），若是你的目標是將MySQL與其餘應用隔離，你能夠考慮綁定mysqld進程到專有的虛擬CPU。可是須要注意的是，這種綁定，在myslqd進程一直不是很忙的狀況下，可能會致使非最優的硬件使用率。在這種狀況下，你可能會設置mysqld進程綁定的虛擬CPU，容許其餘應用程序使用虛擬CPU的一部分或所有。

在某些狀況下，最佳的innodb_thread_concurrency參數設置能夠比虛擬CPU的數量小。按期檢測和分析系統，負載量、用戶數或者工做環境的改變可能都須要對innodb_thread_concurrency參數的設置進行調整。