Oracle MySQL Enterprise 部分
Thread_pool_algorithm:
连接并发调度算法，默认值0 使用一种保守低级别并发的算法，经测试表现结果不错。 值为1的话，并发数量会增大，采用更激进的算法性能，在线程数量一定的时候性能得到5-10%的提升，随着更大的连接数，性能会随之下降。
Thread_pool_high_priority_connection:
该参数影响 如何安排语句的执行顺序，默认值为0，statement会使用 low priority 和 high-priority 两种队列，如果等于1的话，那只会使用high priority 一种队列。
Thread_pool_prio_kickup_timer：
statement 从low priority 队列 移到 high-priority的等待时间。单位为毫秒
Thread_pool_max_unused_threads
该参数限制了sleep thread 所使用的内存。默认值为0，即不限制，当值为N时（N>1）,1个 consumer thread ，n-1 个 reserve threads。当处于sleeping 的thread 达到最大值，再有新的thread 将要 sleep 的时候，该线程只能直接退出。
一个sleeping thread 有两种角色 consumer 和 reserve ，thread pool只允许一个线程是 consumer thread，如果 有一个thread 将要sleep而此时 thread pool 中没有 consumer角色的线程，那该线程会成为 consumer thread；当需要唤醒某个线程的时候，consumer thread是首选，只有当consumer thread 这种角色的 线程不存在时 才会选择 reserve 角色的线程
Thread_pool_size ：thread groups的数量
Thread_pool_stall_limit:thread执行下一个新的 statement的时间间隔。
参数推荐配置：
Thread_pool_size 只读的变量，
主要的存储引擎是：InnoDB， 取值为 16---36 最佳取值为 24---36 对于写密集型的应用，有时候要 低于 36.
主要的存储引擎是：MyISAM：最佳为 4—8，设置的太高 对性能没有显著的影响。
Thread_pool_stall_limit:对于 long-running statement 和 被blocked 的语句 有很大的影响。对于blocked的情况，如果thread pool 能检测到则会开启一个新的线程，针对thread pool 没有检测到该情况，只能通过 该参数来设置超时时间。
该值太高的话，会出现 long-running 的statement 阻挡 更多的短查询。
举例：
When a statement arrives, what is the maximum time it can be delayed before it actually starts executing? Suppose that the following conditions apply:
There are 200 statements queued in the low-priority queue.
There are 10 statements queued in the high-priority queue.
thread_pool_prio_kickup_timer is set to 10000 (10 seconds).
thread_pool_stall_limit is set to 100 (1 second).
In the worst case, the 10 high-priority statements represent 10 transactions that continue executing for a long time. Thus, in the worst case, no statements will be moved to the high-priority queue because it will always already contain statements awaiting execution. After 10 seconds, the new statement is eligible to be moved to the high-priority queue. However, before it can be moved, all the statements before it must be moved as well. This could take another 2 seconds because a maximum of 100 statements per second are moved to the high-priority queue. Now when the statement reaches the high-priority queue, there could potentially be many long-running statements ahead of it. In the worst case, every one of those will become stalled and it will take 1 second for each statement before the next statement is retrieved from the high-priority queue. Thus, in this scenario, it will take 222 seconds before the new statement starts executing.
This example shows a worst case for an application. How to handle it depends on the application. If the application has high requirements for the response time, it should most likely throttle users at a higher level itself. Otherwise, it can use the thread pool configuration parameters to set some kind of a maximum waiting time.