thread_pool_high_prio_mode：

高优先级队列的控制参数，有三个值(transactions/statements/none)，默认是transactions，三个值的含义如下：

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

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

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

thread_pool_high_prio_tickets：

该参数控制每个连接最多语序多少次被放入高优先级队列中，默认为4294967295，注意这个参数只有在thread_pool_high_prio_mode为transactions的时候才有效果。

thread_pool_idle_timeout：

worker线程最大空闲时间，默认为60秒，超过限制后会退出。

thread_pool_max_threads：

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

thread_pool_stall_limit：

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

最终配置如下：

#thread pool

thread_handling=pool-of-threads

#Group的数量，默认为系统CPU的个数，充分利用CPU资源

thread_pool_size=24

#每个group的最大线程数为thread_pool_oversubscribe+1

thread_pool_oversubscribe=3

performance_schema=off

#extra connection，防止线程池满的情况下无法登录MySQL

extra_max_connections = 8

extra_port = 33333

备注：线程池在Percona,MariaDB,Oracle MySQL企业版中提供，Oracle MySQL社区版并不提供。

线程池貌似并不会直接导致内存不回收，网上有说同时开启Thread pool和PS会出现内存泄露，但是

目前Percona server 5.7.21-20+版本已经修复了这个问题，显然是不存在的。

慢查询

由于是生产环境，这个问题拖得时间有点长，那么慢查询会不会影响内存使用问题呢?带着这个问题，查看了慢查询后台列表，在数据库奔溃的前一个时间段，的确有不少慢查询语句。但是这并不能在一定程度上说明问题，由于服务器的 MySql 服务在杀死之前，内存已经见底，此时连接数并不多，也就三四十来个左右，大多处于休眠状态，并且此时已经占用了大部分的Swap空间。也就是说，在资源有限的情况下必定会出现不少慢查询语句。

小结

其实这个"意外"一点也不意外，其实已经发生了多次了。但是还是做个小结吧，因为最终没有确认问题出现在哪里，所以还是发布了吧，万一有专业的DBA遇到类似的问题还可以小小的解惑一下。