關于Mysql thread_concurrency和innodb_thread_concurren

摘要 最近工作上，需要研究一下mysql的優(yōu)化，其中接觸了一個mysql的參數thread_concurrency，需要調查一下thread_concurrency的理論知識，研究一下thread_concurrency是否有助于提升mysql的性能，通過百度和google的幫助以及閱讀官方doc，對mysql thread_concurrency以及innodb_thread_concurrency有了一定的了解，這里簡單的對其中涉及的知識做一些整理。

????原文地址：關于Mysql thread_concurrency和innodb_thread_concurrency參數的一點整理

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

????thread_concurrency變量是針對于Solaris 8及低版本的系統(tǒng)，設置了這個變量mysqld會調用thr_setconcurrency()函數。這個函數允許應用程序給同一時間運行的線程系統(tǒng)提示所需數量的線程。當前的Solaris?版本中這個參數已經沒有作用了。這個參數在mysql 5.6.1中已經被標記為過時，在5.7.2版本的mysql中被移除。???? ??

????對于thread_concurrency參數，這里有兩篇文章可以參考：????

?????thread_concurrency doesn’t do what you expect????

?????mysql中優(yōu)化thread_concurrency的誤區(qū)??????

?????在?Mysql中事務隔離級別與binlog_format的一點理解中，我們簡單的介紹過mysql的兩種存儲引擎：MyISAM和InnoDB，InnoDB支持事務，也是日常開發(fā)中常用的存儲引擎，在InnoDB中，我們可以通過設置參數innodb_thread_concurrency限制線程的數量。????? ??

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

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

????它有助于在最小化的情況下進行線程之間的上下文切換，InnoDB可以使用各種技術來限制操作系統(tǒng)并發(fā)執(zhí)行線程的數量(因此大批量的請求可以在任何一個時間得到處理)。當InnoDB從用戶會話收到一個新的請求，如果線程并發(fā)執(zhí)行的數量達到預定義的限制，那么新的請求會先睡眠一段時間后再次嘗試。在睡眠后不能按計劃執(zhí)行的請求會被放入先入/先出隊列，并最終處理。那些等待獲取鎖的線程則不會被計入到并發(fā)執(zhí)行線程的數量中。???? ? 我們可以通過設置配置參數innodb_thread_concurrency來限制并發(fā)線程的數量，一旦執(zhí)行線程的數量達到這個限制，額外的線程在被放置到對隊列中之前，會睡眠數微秒，可以通過設定參數innodb_thread_sleep_delay來配置睡眠時間。????? ??

????在5.6.3之前的版本中，Mysql要求通過測試和實驗找到innodb_thread_sleep_delay的最優(yōu)值，這個最優(yōu)值可能會因工作負載情況不同而發(fā)生改變。在MySQL 5.6.3及更高版本中，你可以通過設置參數innodb_adaptive_max_sleep_delay為innodb_thread_sleep_delay設置最大允許的值，InnoDB會根據當前線程調度活動自動調整innodb_thread_sleep_delay的值，這種動態(tài)調整機制有助于工作的線程，在系統(tǒng)負載低時或系統(tǒng)接近滿負荷運轉時，都能夠順利的調度。???? ??

????在MySQL 和 InnoDB之前的版本系列中，innodb_thread_concurrency的默認值，以及其隱含的限制并發(fā)線程執(zhí)行的數量都進行過調整。在當前最新版本的mysql中，innodb_thread_concurrency的默認值為0，它表示默認情況下不限制線程并發(fā)執(zhí)行的數量。???? ??

????需要注意的是，InnoDB導致線程睡眠當且僅當并發(fā)線程的數量是有限的時候。如果對線程并發(fā)執(zhí)行的數量沒有限制，所有的請求都會被認為是可調度的，也就是說，如果innodb_thread_concurrency的值設置為0，innodb_thread_sleep_delay的值將會被忽略。???? ??

????當有對線程數量進行限制（即innodb_thread_concurrency參數> 0），InnoDB通過允許多個請求在一個SQL語句執(zhí)行過程中進入InnoDB，而不必遵守innodb_thread_concurrency設置的參數限額，來減少上下文的切換開銷，當一個SQL語句(如join語句)包含在InnoDB的多行操作時，InnoDB會分配?指定數量的“入場券”，允許一個線程反復使用最小的開銷。???? ??

????當一個新的SQL語句開始，當前線程沒有“入場券”，它就必須遵守innodb_thread_concurrency參數設置，一旦這個線程有權進入InnoDB，它會被分配一個“入場券”，它可以通過這個“入場券”用于隨后進入InnoDB執(zhí)行行操作，如果“入場券”使用完畢，該線程將會被驅逐，innodb_thread_concurrency參數會被放回到先入/先出隊列中等待的線程等待再次觀察。一旦這個線程再次有權進入InnoDB，“入場券”又會被重新分配，我們可以通過設置全局參數innodb_concurrency_tickets來指定“入場券”的數量，默認情況下是5000。正在等待獲取鎖的線程，一旦鎖可用，會被立即分配一個“入場券”。??????

???? 這些參數的正確值取決于當前系統(tǒng)環(huán)境和負載情況。嘗試各種不同的值，以確定哪些值適用于當前應用程序。在限制并發(fā)執(zhí)行的線程數之前，在多核及多處理器的計算機上，檢查一下InnoDB的配置參數是否可以改善性能，比如innodb_adaptive_hash_index。???? ??

????對于innodb_thread_concurrency參數的作用及配置，這里有兩篇文章可以參考：

???????innodb_thread_concurrency的作用與改良???

??????innoDb 的多線程并發(fā)調優(yōu)?? ? ??

????在官方doc上，對于innodb_thread_concurrency的使用，也給出了一些建議，如下：

如果一個工作負載中，并發(fā)用戶線程的數量小于64，建議設置innodb_thread_concurrency=0；

如果工作負載一直較為嚴重甚至偶爾達到頂峰，建議先設置innodb_thread_concurrency=128，并通過不斷的降低這個參數，96, 80, 64等等，直到發(fā)現(xiàn)能夠提供最佳性能的線程數，例如，假設系統(tǒng)通常有40到50個用戶，但定期的數量增加至60，70，甚至200。你會發(fā)現(xiàn)，性能在80個并發(fā)用戶設置時表現(xiàn)穩(wěn)定，如果高于這個數，性能反而下降。在這種情況下，建議設置innodb_thread_concurrency參數為80，以避免影響性能。

如果你不希望InnoDB使用的虛擬CPU數量比用戶線程使用的虛擬CPU更多（比如20個虛擬CPU），建議通過設置innodb_thread_concurrency 參數為這個值（也可能更低，這取決于性能體現(xiàn)），如果你的目標是將MySQL與其他應用隔離，你可以考慮綁定mysqld進程到專有的虛擬CPU。但是需 要注意的是，這種綁定，在myslqd進程一直不是很忙的情況下，可能會導致非最優(yōu)的硬件使用率。在這種情況下，你可能會設置mysqld進程綁定的虛擬 CPU，允許其他應用程序使用虛擬CPU的一部分或全部。

在某些情況下，最佳的innodb_thread_concurrency參數設置可以比虛擬CPU的數量小。

定期檢測和分析系統(tǒng)，負載量、用戶數或者工作環(huán)境的改變可能都需要對innodb_thread_concurrency參數的設置進行調整。