關(guān)于Mysql thread_concurrency和innodb_thread_concurren

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

????原文地址：關(guān)于Mysql thread_concurrency和innodb_thread_concurrency參數(shù)的一點(diǎn)整理

????首先，最重要的一點(diǎn)，這個(gè)參數(shù)已經(jīng)在最新版本的mysql中被移除了，官方最新5.7版本的doc上面對thread_concurrency有這樣的說明：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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