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才有效。

percona的博客上有人写了一篇文章说thread_concurrency不是你想的那样，修改这个参数是浪费时间。我谨慎表示认同。

并且还说这个参数在5.6.1之后会被废弃。

还有一些中文文章也认为这个参数没有意义

至少经过我实践，这个参数在linux下面是有效的。默认是10，我改成0并被系统强制变成1之后，造成了经常阻塞的问题。目前我设置的是16，等于CPU线程数。

我为什么会蛋疼地以为把这个参数改成0会有效呢，大概是因为受了innodb_thread_concurrency的影响，innodb_thread_concurrency是可以并且推荐改成0的。

在我看来这个参数似乎除了坑人之外真的没有什么别的作用了，默认thread_concurrency=10就已经足够可用了，确实不需要修改。早一点升级到5.6告别这个参数吧。
 

最近在优化mysql,其中很多人都在配置文件中添加了thread_concurrency,大多数人给出的描述是：

“设置thread_concurrency的值的正确与否, 对mysql的性能影响很大, 在多个cpu(或多核)的情况下，错误设置了thread_concurrency的值, 会导致mysql不能充分利用多cpu(或多核), 出现同一时刻只能一个cpu(或核)在工作的情况。

thread_concurrency应设为CPU核数的2倍. 比如有一个双核的CPU, 那么thread_concurrency的应该为4; 2个双核的cpu, thread_concurrency的值应为8.”

具体修改方法是：

[mysqld]

thread_concurrency=8

殊不知，thread_concurrency是在特定场合下才能使用的，参考 ：

这个变量是针对Solaris系统的，如果设置这个变量的话，mysqld就会调用thr_setconcurrency()。这个函数使应用程序给同一时间运行的线程系统提供期望的线程数目。

另外需要说明的是：这个参数到5.6版本就去掉了