Step1：请求连接到MySQL，根据threadid%thread_pool_size肯定落在哪个group；

Step2：group中的listener线程监听到地点的group有新的请求今后，检查队列中是否有请求还未处理。如不雅没有，则本身转换为worker线程急速处理该请求，如不雅队列中还有未处理的请求，则将对应请求放到队列中，让其他的线程处理；

Step3：group中的thread线程检查队列的请求，如不雅队列中有请求，则进行处理，如不雅没有请求，则休眠，一向没有被唤醒，跨越thread_pool_idle_timeout后就主动退出。线程停止。当然，获取请求之前会先检查group中的running线程数是否跨越thread_pool_oversubscribe+1，如不雅跨越也会休眠；

Step4：timer线程按期检查各个group是否有壅塞，如不雅有，就对wokrer线程进行唤醒或者创建一个新的worker线程。

4、Thread Pool的分派机制

线程池会根据参数thread_pool_size的大年夜小分成若干的group，每个group各自保护客户端提议的连接，当客户端提议连接到MySQL的时刻，MySQL会跟进连接的线程id（thread_id）对thread_pool_size进行取模，大年夜而落到对应的group。

thread_pool_oversubscribe参数控制每个group的最大年夜并发线程数，每个group的最大年夜并发线程数为thread_pool_oversubscribe+1个。若对应的group达到了最大年夜的并发线程数，则对应的连接就须要等待。这个分派机制在某个group中有多个慢SQL的场景下会导致通俗的SQL运行时光很长，这个问题会在后面做具体描述。

MySQL线程池参数解释

出现超时的时刻，有很多的load线程到导入数据。也就是说那个时刻有部分线程比较慢的情况。那么会不会是某个group的线程满了，大年夜而导致新分派的线程等待？

• thread_handling

为了构建快速重现情况，我将参数调剂如下：

该参数是设备线程模型，默认情况是one-thread-per-connection，即不启用线程池；将该参数设置为pool-of-threads即启用了线程池。

• thread_pool_size

该参数是设置线程池的Group的数量，默认为体系CPU的个数，充分应用CPU资本。

• thread_pool_oversubscribe

该参数设置group中的最大年夜线程数，每个group的最大年夜线程数为thread_pool_oversubscribe+1，留意listener线程不包含在内。

• thread_pool_high_prio_mode

关于线程池参数不多，应用show variables like 'thread%'可以看到如下图的参数，下面就一个一个来解析：

高优先级队列的┞菲握参数，有三个值（transactions/statements/none），默认是transactions，三个值的含义如下：

transactions：对于已经启动事务的语句放到高优先级队列中，不过还取决于后面的thread_pool_high_prio_tickets参数。

下面描述极简的Thread Pool运作，只是简单描述，省略了大年夜量的复杂逻辑，请不要挑刺~

statements：这个模式所有的语句都邑放到高优先级队列中，不会应用到低优先级队列。

none：这个模式不应用高优先级队列。

• thread_pool_high_prio_tickets

worker线程最大年夜余暇时光，默认为60秒，跨越限制后会退出。

• thread_pool_max_threads

该参数用来限制线程池最大年夜的线程数，跨越该限制后将无法再创建更多的线程，默认为100000。

• thread_pool_stall_limit

该参数设置timer线程的检测group是否异常的时光距离，默认为500ms。

三、MySQL线程池的应用

线程池的应用比较简单，只须要添加设备后重启实例即可。

具体设备如下：

#thread pool  
thread_handling=pool-of-threads  
thread_pool_oversubscribe=3 
thread_pool_size=24  
performance_schema=off  
#extra connection  
extra_max_connections = 8  
extra_port = 33333 

备注：其他参数默认即可

以上具体的参数在前面已做具体解释，下面是设备中须要留意的两个点：

1、之所以添加performance_schema=off，是因为测试过程中发明Thread pool和PS同时开启的时刻会出现内存泄漏问题（后文会具体论述）；

具体的检测办法为：经由过程queue_event_count的值和IO义务队列是否为空来断定线程组是否为壅塞状况。

我应用脚本，并提议12个线程请求，每个线程请求都运行select sleep(2)，那么在Group1和Group2都余暇的情况下，运行情况如下：

2、添加extra connection是防止线程池满的情况下无法登录MySQL，是以特意用治理端口，以备紧急的情况下应用；

重启实例后，可以经由过程show variables like '%thread%';来查看设备的参数是否生效。

在应用线程池的过程中，我碰到了几个问题，这里也趁便做个总结：

内存泄漏问题

DB启用线程池后，内存飙升了8G阁下，如下图：

　　推荐阅读

　　第一季度将过，AI巨头们交出了怎样一份成绩单？

沙龙晃荡 | 3月31日 京东、微博、华为拭魅战专家与你合营商量容器技巧实践！ 亚马逊：明星产品Alexa下的难堪时刻根据大年夜邀请函显示的信息猜测，此次重要针对师生和教导方面，没有惊艳的新>>>详细阅读

本文标题：关于MySQL线程池，这也许是目前最全面的实用帖！

地址：http://www.17bianji.com/lsqh/40924.html

 1/2    1