mysql參數thread_concurrency的設定問題

已經在一個非常奇怪的資料庫問題上卡了很久，slow log裡面全是一些非常基本的sql語句，主鍵查詢或者根據主鍵更新簡單欄位，本來應該是毫秒級返回結果的sql，居然總是逾時。innodb分明是行級鎖，本來這些單行操作是innodb的優勢項目，應該毫無壓力的，居然成為了瓶頸。

反覆調整參數，並且請教了專家之後仍然沒有很好地解決，之前增加了

innodb_purge_threads = 32 # 5.6之後才支援大於1, 5.5上會自動變成1
讓每隔10秒的purge操作開獨立的進程有一定的改善，但是仍然還是有很多阻塞的情況和很多slow log。

今天在安裝一台新mysql的時候看到這樣一段錯誤訊息

[Warning] option 'thread_concurrency': unsigned value 0 adjusted to 1
我非常驚訝，因為我一直以為thread_concurrency=0的意思是不設定thread_concurrency，即無限。如果thread_concurrency=1，那就意味著mysql始終只能有一個並發thread，這顯然會造成阻塞，嚴重影響效能。

把這個參數改成16(cpu匯流排程數)之後，這個阻塞的問題徹底解決了。在top裡經常能看到mysqlCPU佔用率超過200%以上的瞬間，而原來mysql很少能超過200%。slow log裡面也不再出現那些簡單查詢的日誌了。

查了一下相關資訊，眾說紛紜，有很多人包括官方文檔說這個參數沒有意義，僅僅針對solaris才有效。

 

並且還說這個參數在5.6.1之後會被廢棄。

還有一些中文文章也認為這個參數沒有意義

注意，這個參數是針對Solaris系統的，如果使用Linux系統，也就不需要設定這個參數，除非你使用Solaris系統

 

至少經過我實踐，這個參數在linux下面是有效。預設是10，我改成0並被系統強制變成1之後，造成了經常阻塞的問題。目前我設定的是16，等於CPU線程數。

我為什麼會蛋疼地以為把這個參數改成0會有效呢，大概是因為受了innodb_thread_concurrency的影響，innodb_thread_concurrency是可以並且推薦改成0的。

在我看來這個參數似乎除了坑人之外真的沒有什麼別的作用了，預設thread_concurrency=10就已經足夠可用了，確實不需要修改。早一點升級到5.6告別這個參數吧。