共计 3157 个字符，预计需要花费 8 分钟才能阅读完成。
MySQL 线程池只在 Percona，MariaDB，Oracle MySQL 企业版中提供。Oracle MySQL 社区版并不提供。
在传统方式下，MySQL 线程调度方式有两种：每个连接一个线程 (one-thread-per-connection) 和所有连接一个线程（no-threads）。在实际生产中，一般用的是前者。即每当有一个客户端连接到 MySQL 服务器，MySQL 服务器都会为该客户端创建一个单独的线程。连接数越多，则相应的线程会越多。
如果大部分线程处于空闲状态，则不会对服务器的性能造成很大的影响。但如果同时执行的线程太多，会导致操作系统频繁的上下文切换。
引入线程池的目的，就是为了减少同时运行的线程的数量，降低上下文切换的次数。
线程池是 MariaDB 最先实现的，有两种实现方式，分别对应 Windows 和 Unix 操作系统。其中，Windows 系统上是直接利用操作系统的本地缓冲池功能，Unix 系统上则是自己实现的。这导致两个操作系统上的系统变量有所不同。
下面，基于 Percona 5.6.31 版本看看线程池的相关参数
thread_handling
默认是 one-thread-per-connection，如果要使用连接池功能，则必须设置为 pool-of-threads。
thread_pool_size
用于设置线程池中线程组的个数，默认为服务器 CPU 的核心数。实现分组的目的是为了把每个分组对应到每个 CPU 核心上，这样在同一时间点，每个分组可调用 1 个线程进行执行。
thread_pool_max_threads
控制线程池的最大线程数，若该值为 1000，代表线程池中所能创建的最大线程数不能超过 1000。
This variable can be used to limit the maximum number of threads in the pool. Once this number is reached no new threads will be created.
thread_pool_oversubscribe
用于控制单个 CPU 核心在同一时间活跃的线程数。类似于一种“超频”的概念
The higher the value of this parameter the more threads can be run at the same time, if the values is lower than 3 it could lead to more sleeps and wake-ups
thread_pool_stall_limit
线程池中无可用线程时，thread_pool_stall_limit 决定等待多久后创建新线程，单位为毫秒。默认是 500。
在合适范围内，该值越大，MySQL 服务器的整体处理性能就越好，因为较少数量的线程，会降低对于系统资源的征用。但是，并不是越大越好，因为该值越大，新线程的创建将等待更长的时间，用户的查询延迟就会越明显。
The number of milliseconds before a running thread is considered stalled. When this limit is reached thread pool will wake up or create another thread. This is being used to prevent a long-running query from monopolizing the pool.
thread_pool_idle_timeout
设置空闲线程销毁前的等待时间，单位为秒，默认是 60。
用户可以根据自己的业务场景来调整该参数的值，如果设置得太短，会导致线程频繁的销毁与创建，如果设置的太长，则会导致线程池中的线程数长时间不会下降。
This variable can be used to limit the time an idle thread should wait before exiting.
extra_port
用于设置 MySQL 服务端口之外的端口，供管理员管理服务器。
This variable can be used to specify additional port Percona Server will listen on. This can be used in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled.
extra_max_connections
用于设置 extra_port 端口允许的最大连接数，通过 extra_port 端口创建的连接，采用的是 one-thread-per-connection 的方式
This variable can be used to specify the maximum allowed number of connections plus one extra SUPER users connection on the extra_port. This can be used with the extra_port variable to access the server in case no new connections can be established due to all worker threads being busy or being locked when pool-of-threads feature is enabled。
除此之外，Percona 还新增了两个参数用于实现优先级队列。
thread_pool_high_prio_mode
线程池分组内的待处理任务会放到任务队列中，等待 worker 线程处理。
每个分组有两个队列：高优先级队列和普通队列，worker 线程先从高优先队列取 event 处理，只有当高优先队列为空时才从普通队列取 event 处理。
通过优先级队列，可以让已经开启的事务或短事务得到优先处理，及时提交释放锁等资源。
该参数可设置三种模式：
transactions：默认的，只有一个已经开启了事务的 SQL，并且 thread_pool_high_prio_tickets 不为 0，才会进入到高优先级队列中，每个连接在 thread_pool_high_prio_tickets 次被放到优先队列中后，会移到普通队列中。
statements：单独的 SQL 总是进入高优先级队列
none：禁用高优先级队列功能，所有的连接都放到普通队列中处理。
thread_pool_high_prio_tickets
给每个新的连接授予的 tickets 大小
This variable controls the high priority queue policy. Each new connection is assigned this many tickets to enter the high priority queue. Setting this variable to 0 will disable the high priority queue. 默认为 4294967295。
线程池的适用场景：
适用于有大量短查询的业务场景
在该场景下，每个连接一个线程，过多的连接数很容易达到连接数的最大值，同时，过多的活跃线程会导致频繁的上下文切换。此时，可使用线程池，因为是短查询，不会有某个连接长时间占用线程池中的线程，所以几乎不会影响客户端请求的响应时间，并且，随着连接数的增加，线程池中的线程数被控制都在一定范围内，减轻了系统的压力。
在有大量长查询的业务场景下不适合使用线程池
在该场景下，长查询可能会占据线程池的所有线程，导致线程池出现效率低效的情况，客户端设置不能进行连接。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-08/133925.htm
