mysql thread_终于解决了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告别这个参数吧。

觉得文章有用？立即：

和朋友一起 共学习 共进步！

猜想失败，您看看下面的文章有用吗？