mysql 线程池大小设置_MySQL线程池参数解析

线程池是数据库系统非常重要功能，然而MySQL社区版并不包含线程池功能，不过好在MySQL的Percona发行版本提供了这个功能，除此之外，MySQL的企业版也提供线程池，从性价比上说，Percona显然更有吸引力，因为它是开源、免费的，下面将讨论Percona版线程池的相关参数。

Percona MySQL 线程池相关参数：

thread_pool_max_threads：默认值 100000，线程池中的最大线程数。

thread_pool_size：用于设置线程池中线程组的个数，默认为服务器CPU的核心数。实现分组的目的是为了把每个分组对应到每个CPU核心上，这样在同一时间点，每个分组可调用1个线程进行执行。

thread_pool_oversubscribe：默认值为3，用于控制单个CPU核心在同一时间活跃的线程数。类似于一种“超频”的概念，线程组里正在执行的线程数量，值越大，表示在同一时间，有更多的线程能够运行。如果这个值小于3，将会导致频繁的线程睡眠和唤醒。

thread_pool_stall_limit：线程池中无可用线程时，thread_pool_stall_limit决定等待多久后创建新线程，单位为毫秒。默认是500。

在合适范围内，该值越大，MySQL服务器的整体处理性能就越好，因为较少数量的线程，会降低对于系统资源的征用。但是，并不是越大越好，因为该值越大，新线程的创建将等待更长的时间，用户的查询延迟就会越明显。

thread_pool_idle_timeout：默认值60秒，空闲线程在空闲多长时间之后退出。

thread_pool_high_prio_tickets：默认值 4294967295。控制高优先级队列策略， 给每个新的连接授予的tickets大小，如果该值设置为0，表示禁止进入高优先级队列。

thread_pool_high_prio_mode：取值范围 transactions, statements, none，默认值 transactions。该参数提供了对每个连接在高优先级队列更加细粒度的控制。

线程池分组内的待处理任务会放到任务队列中，等待worker线程处理。

每个分组有两个队列，高优先级队列和普通队列，worker线程先从高优先队列取event处理，只有当高优先队列为空时才从普通队列取event处理。

通过优先级队列，可以让已经开启的事务或短事务得到优先处理，及时提交释放锁等资源。

该参数可设置三种模式：

transactions：默认的，只有一个已经开启了事务的SQL，并且thread_pool_high_prio_tickets不为0，才会进入到高优先级队列中，每个连接在thread_pool_high_prio_tickets次被放到优先队列中后，会移到普通队列中。statements：单独的SQL总是进入高优先级队列。none：禁用高优先级队列功能，所有的连接都放到普通队列中处理。Percona MySQL 线程池相关状态变量：

Threadpool_idle_threads：表示线程池中的空闲线程数。Threadpool_threads：表示线程池中的所有线程数。线程池处理策略

线程池寻找新的连接来处理，其策略是先检查高优先级队列，如果为空，再去检查普通队列。对于已经开始的事务，其后续的执行事件会放到高优先级队列执行。当tickets变为0时，连接被放入普通队列。

thread_pool_high_prio_mode 参数的引入为了解决某些场景，如对于某些连接，不管是包含多个sql的事务执行还是autocommit，它都希望它的所有sql语句能够得到快速执行，又或者某些连接，希望请求低优先级执行自己的sql，比如监控类的连接。

有一个场景在高并发条件下会限制线程池的性能甚至导致死锁。在高并发条件下，线程池中活跃的线程达到thread_pool_oversubscribe限制，但是这些活跃的线程中全部或者大多数是在等待锁，而锁的持有者并不在线程池中。线程池中的活跃线程和等待锁的线程会积累的越来越多，最终达到 thread_pool_max_threads 限制，降低了性能。另外，如果这时持有锁的连接，被调度到连接池中，发现无法创建更多的线程，这时会导致死锁，持有锁的连接会释放锁并回滚事务。这种场景的解决方案是在活跃线程达到thread_pool_oversubscribe限制时，不要开始新的事务或者创建新的线程，直到已经开始的事务被处理。

MySQL