關於Mysql thread_concurrency和innodb_thread_concurren

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

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

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

    對於thread_concurrency參數，這裏有兩篇文章能夠參考：   

     thread_concurrency doesn’t do what you expect   

     mysql中優化thread_concurrency的誤區     

     在 Mysql中事務隔離級別與binlog_format的一點理解中，咱們簡單的介紹過mysql的兩種存儲引擎：MyISAM和InnoDB，InnoDB支持事務，也是平常開發中經常使用的存儲引擎，在InnoDB中，咱們能夠經過設置參數innodb_thread_concurrency限制線程的數量。       

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

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

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

    在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的多行操做時，InnoDB會分配 指定數量的「入場券」，容許一個線程反覆使用最小的開銷。      

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

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

    對於innodb_thread_concurrency參數的做用及配置，這裏有兩篇文章能夠參考：

       innodb_thread_concurrency的做用與改良  

      innoDb 的多線程併發調優      

    在官方doc上，對於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參數的設置進行調整。