MySQL Innodb 并发涉及参数

1 参数做用

    MySQL的各个插件式引擎中，都会对事务及线程作必定的处理和优化。在Innodb引擎中，老是尝试保持 innodb内 操做系统的线程数（暂命名为innodb_thread） 应该小于或等于 系统可提供给innodb处理事务的线程数(暂命名为system_innodb_thread)。在大多数状况下，innodb_thread都不会指定一个限制值，而是让它想要多少直接申请多少。

    当 innodb_thread 大于system_innodb_thread 时，持续时间较长时，会致使服务器的线程资源被数据库使用，CPU可能居高不下，甚至引起宕机。

    这个时候，Innodb内部能够提供一个参数来限制 并发线程（同一时刻可处理的请求数），当并发数达到 并发线程限制数时，再接收到一个新的请求，那么这个请求须要在下次请求前先sleep一段时间，若是sleep后再请求仍是没有多余线程提供其执行，那么，它就会进入到先进先出的队列中等待执行。这里注意下，等待线程，不计入 innodb_thread 。innodb_thread_concurrency 参数所以而来。

   能够经过innodb_thread_concurrency 来调节  并发线程数的限制值，使用innodb_thread_sleep_delay来调整当 并发 thread 到达 innodb_thread_concurrency时须要sleep的时间。当请求被innodb接受的时候，会得到一个 消费凭证 innodb_concurrency_tickets (默认5000次)，当这个请求中有多个SQL被执行的时候，每执行一次，消费一次tickets，在次数用完以前，该线程从新请求时无须再进行前面 thread 是否达到 并发限制值的检查。

   同时 innodb_commit_concurrency也控制了多线程并发提交的数量。若是 innodb_thread_concurrency  设置的有点大innodb_commit_concurrency应该作出相应的调整，不然会形成大量线程阻塞。

   因此，跟并发相关的有这几个参数设置：innodb_thread_concurrency、innodb_thread_sleep_delay、innodb_concurrency_tickets、innodb_commit_concurrency。

跟innodb_thread_concurrency类似的参数有 thread_concurrency ，可是它在5.6版本的官方文档中已被标识为过期，在5.7.2版本废除了该参数，因此咱们这里不涉及对该参数的测试及描述。

2 参数设置

2.1 innodb_thread_concurrency

2.1.1 默认值

   innodb_thread_concurrency默认是0，则表示没有并发线程数限制，全部请求都会直接请求线程执行。注意：当 innodb_thread_concurrency 设置为0时，则innodb_thread_sleep_delay的设置将会被忽略，不起做用。若是数据库没出现性能问题时，使用默认值便可。

2.1.2 大于0

   当innodb_thread_concurrency>0，则表示有 并发数限制，当一个新的请求发起时，会检查当前并发线程数是否达到了 innodb_thread_concurrency的限制值，若是有，则须要sleep一段时间（sleep的设置详见下一部分），而后再再次请求，若是再次请求时，当前并发数仍是达到限制值，那么就会进入FIFO队列等待执行。当进入到内核执行时，会获得一个 消费凭证 ticket，则这个线程，在后面的屡次进入innodb执行操做是都不须要重复上面的检查步骤，当把次数消费完，那么这个线程就会被驱逐，等待下次再次进入Innodb，再从新分配ticket。

2.1.3 建议配置（来自官网）

• 当并发用户线程数量小于64，建议设置innodb_thread_concurrency=0；
• 若是负载不稳定，时而低，时而高到峰值，建议先设置innodb_thread_concurrency=128，并经过不断的下降这个参数，96, 80, 64等等，直到发现可以提供最佳性能的线程数，例如，假设系统一般有40到50个用户，但按期的数量增长至60，70，甚至200。你会发现，性能在80个并发用户设置时表现稳定，若是高于这个数，性能反而降低。在这种状况下，建议设置innodb_thread_concurrency参数为80，以免影响性能；
• 若是DB服务器上还容许其余应用，须要限制mysql的线程使用状况，则能够设置可分配给DB的线程数，可是不建议DB上跑其余应用，也不建议这么设置，由于这样可能致使数据库没有对硬件最优使用；
• 设置太高值，可能会由于系统资源内部争夺致使性能降低；
• 在大多数状况下，最佳的值是小于并接近虚拟CPU的个数；
• 按期监控和分析DB，由于随着数据库负载的变化，业务的增长，innodb_thread_concurrency也须要动态的调整。

2.2 innodb_thread_sleep_delay

   5.6.3版本前，须要反复测试才能肯定innodb_thread_sleep_delay值，而且固定为一个值，在5.6.3版本后，由于 Innodb 自动调整innodb_thread_sleep_delay参数：

• Innodb_adaptive_max_sleep_delay：最大sleep的时间，微秒为单位

能够经过设置参数 innodb_adaptive_max_sleep_delay 来限制 innodb_thread_sleep_delay的最大值，不设置 innodb_thread_sleep_delay的取值状况，让Innodb自动跟进负载来调整，当系统负荷较高时，Innodb动态调整slee时间可以使得数据库稳定运行。

2.3 innodb_commit_concurrency

   该值只能为默认值0，mysql不限制并发提交。大于0表示容许N个事务在同一时间点提交，N的范围是0-1000。 

    注意事项：mysqld运行时，不准把innodb_commit_concurrency 的值从0改成非0，或非0的值改成0；但容许从N改成M（N及M均大于0）

2.4 innodb_concurrency_tickets

   默认是5000（基于5.6，5.7）。

   若是innodb_concurrency_tickets设置小些，适用于小事物操做较多的系统，能够快速使用完线程后退出来，提供给其余请求使用；而对于大事务来讲，可能会循环进入等待队列中等待执行完成，这会耗费更多时间及资源；若是innodb_concurrency_tickets设置大些，适用于大事务频繁操做的系统，这样大事务则不须要频繁进入queue等待队列，能够经过较少的请求来处理；可是对于小事务来讲，则意味着他们要等待更长的时候，才能排队进入到内核执行。因此，当innodb_thread_concurrency>0时，须要上下调整 innodb_concurrency_tickets ，使其达到最佳性能。能够经过show engine innodb status 的queue查看，也能够经过INFORMATION_SCHEMA.INNODB_TRX 的TRX_CONCURRENCY_TICKETS查看消费次数状况。