对于MySQL5.5来说只有企业版本中含有 Thread Pool，但幸运的是 mariadb 5.1中就已存在该功能，mariadb 5.5 中进行了改进。

    本篇暂且介绍FAQ：后期会放出其工作原理及使用情况。

    商业版本中 5.5.16 添加了 thread  handling model （线程池）来应对多客户连接问题。代替一个session 一个线程的问题。在MariaDB 5.1-5.3 中已经实现该功能，在MariaDB 5.5中实现优化，动态的线程池等，这个和商业版本有少许区别，具体查看https://kb.askmonty.org/en/thread-pool-in-mariadb-55/

    适用threadpool场景:查询相对较短，或者CPU比较吃紧。或者可以通过 threadpool 限制线程数量来达到节省内存的目的。

    安装条件：Linux 内核需高于2.6.9 版本

    在某些场合下 效果可能不是很理想：

    1、突发的工作负载，长时间不活动和很多短期的高活跃连接，这个是有可以通过调整等待时间来应对这样的情况。Thread_pool_idle_timeout

    2、并发很多，且长时间执行的查询，一个线程执行的时候 都是重新创建，也不会等待threadpool 释放资源，这种出现在数据仓库的情景。长时间运行的查询会阻塞其他查询的执行，对于拥有阻塞监测或者其他抢占机制 可以固定 阻塞时长

    3、一些简单的查询总是很快执行完毕。无论你的机器负载多高，在拥有 threadpool 的时候，query 可能会出现排队情况，比如select  1；可能会比thread-per-connection消耗更多时间。

FAQ：

    线程池解决的问题：

    1、太多的线程堆栈，几乎让CPU的缓存无用，线程池 可以减少CPU占用内存空间。

    2、建立过多的线程容易导致过多的上下文切换，解决办法是是维持一组低于客户端连接数量，平衡mysql连接并保持较高性能。

    3、过多的事务并发执行导致资源争用，延长热锁争用

    线程池如何限控制并发的会话线程和事务来达到最优的性能和吞吐量？

    该线程池使用“分步解决”的方法来限制和平衡并发量，线程池将connections 和threads分开，这样thread 执行从connections 接受的statement，两者并没有固定的绑定在一起。线程池根据配置的已划分优先级的thread group 来处理连接。

    线程池和客户端连接池有什么区别：

    两者的职责不是同的：
客户端连接池：处于客户端一边，client不会不断的连接或断开server，它被设计为 缓存空闲的连接来被其他的connections 使用。减小建立和拆除connections的开销。Client pool 对查询处理能力和后端数据库的负载时不可见的。相比之下 thread pool 是处在MySQL 这一端的。它们被设计为管理已经建立的 connections 和接受到的query

    线程池在连接太多的时候怎么动态扩展，在链接减少的时候怎么收缩；线程池本身的开销怎样控制；是否能够利用OS原生的线程池来直接提供服务等一系列问题都是引入线程池需要考虑的。
线程相互等待的问题。如果有长链接和短链接同时存在，那么短链接可能要等到长链接执行完所有操作，才能被轮到，执行时间不可控.
MariaDB充分考虑和优化了thread pool的实现，并提供了一系列参数给用户调整线程池的配置(thread_pool_size, thread_pool_stall_limit, thread_pool_idle_timeout, thread_pool_oversubscribe )和一些状态值（threadpool_threads，threadpool_idle_threads）提供给用户查询线程池使用情况。从实现方面来看，MariaDB相对MySQL Enterprise的线程池会使用原生的系统提供的线程池，并且考虑到各个系统OS的特点，优化多路IO（IO multiplexing）接口的使用。 具体信息可以参考：http://kb.askmonty.org/en/thread-pool-in-mariadb-55/