很多人都讨论了这个问题，参数innodb_thread_concurrency限制了InnoDB内部线程的数量。例如当有query需要InnoDB处理时，InnoDB首先会检查一下当前的内部线程数是不是超过了innodb_thread_concurrency的限制，如果超出则会让当前线程sleep一会儿，再试，如果还是受限，则会进入一个FIFO的队列。如果innodb_thread_concurrency设置成0表示，内部线程数量将不受限制（注：innodb_thread_concurrency值在不同的版本意义略有不同）。

我不知道多大合适。我的经验值设置成64就够了，正常情况，应用并发不会超过这个值。

如果设置成0，会让InnoDB的内部线程不受限制，如果你高并发的IO-bound的应用，很可能在InnoDB内部累计很多的并发等待IO的线程，主机的Load会很高，但是数据库依然会正常运行。

从5.1.11开始这个值的默认值是8，意味着，InnoDB会限制内部线程数不超过8。如果是高并发的应用，你的MySQL能力可能会受到这个参数的限制。对于很多情况这个值有偏小的，并发量可能会比8大，这时参数innodb_thread_concurrency就会成为InnoDB的瓶颈。对于一个16核的系统，处理的并发很多时候都会大于8，而受cpu核数限制，太多的线程会在CPU切换上消耗过多资源。

但是如果你系统并发量始终都是小于8的，那么设置成一个大于8的值并没有意义。

通过supersmack模拟了128个线程并发，做了5组对比测试：

最后，提一下，没事不要在生产环境动态更改innodb_thread_concurrency，很危险：Bug 40760。

参考：

1. MySQL Manual

2. MySQL: innodb_thread_concurrency beast

3. do we still need innodb_thread_concurrency

4. Mess with innodb_thread_concurrency

5. InnoDB线程并发检查机制

6. MySQL Bugs