本节提供了如何设置线程池系统变量以获得最佳性能的指导原则，使用诸如每秒事务数这样的度量标准进行度量。

thread_pool_size是控制线程池性能的最重要参数。只能在服务器启动时设置。我们测试线程池的经验表明:

另一个系统变量，thread_pool_stall_limit，对于处理阻塞和长时间运行的语句很重要。如果所有阻塞MySQL服务器的调用都报告给线程池，那么线程池总是知道什么时候执行线程被阻塞。然而，这可能并不总是正确的。例如，块可能出现在未使用线程池回调检测的代码中。对于这种情况，线程池必须能够识别似乎被阻塞的线程。方法可以通过一个超时来实现这一点，该超时可以使用thread_pool_stall_limit系统变量，其值以10ms为单位测量。该参数确保服务器不会完全阻塞。的价值thread_pool_stall_limit具有6秒的上限，以防止服务器死锁的风险。

thread_pool_stall_limit还允许线程池处理长时间运行的语句。如果允许长时间运行的语句阻塞线程组，则分配给该组的所有其他连接都将被阻塞，并且在长时间运行的语句完成之前无法开始执行。在最坏的情况下，这可能需要几个小时甚至几天的时间。

的价值thread_pool_stall_limit应该这样选择，即执行时间超过其值的语句将被视为暂停。停顿语句会产生很多额外的开销，因为它们涉及到额外的上下文切换，在某些情况下甚至是额外的线程创建。另一方面，设置thread_pool_stall_limit参数过高意味着长时间运行的语句会阻塞大量短时间运行的语句。短等待值允许线程更快地启动。短值对于避免死锁情况也更好。长等待值对于包含长时间运行语句的工作负载非常有用，可以避免在当前语句执行时启动太多新语句。

假设一个服务器执行一个工作负载，其中99.9%的语句在100ms内完成，即使服务器已经加载，其余语句平均分布在100ms到2小时之间。在这种情况下，设置是有意义的thread_pool_stall_limit至10 (10 × 10ms = 100ms)。默认值6 (60ms)适用于主要执行非常简单语句的服务器。

的thread_pool_stall_limit参数可以在运行时更改，以使您能够达到适合服务器工作负载的平衡。假设tp_thread_group_stats表启用后，您可以使用下面的查询来确定执行语句中暂停的部分:

SELECT SUM(STALLED_QUERIES_EXECUTED) / SUM(QUERIES_EXECUTED) FROM performance_schema.tp_thread_group_stats;

这个数字应该越低越好。的值可以降低报表停顿的可能性thread_pool_stall_limit．

当一条语句到达时，它在实际开始执行之前可以延迟的最大时间是多少?假设下列条件适用:

在最坏的情况下，10个高优先级语句代表10个长时间继续执行的事务。因此，在最坏的情况下，没有语句可以移动到高优先级队列，因为它总是包含等待执行的语句。10秒后，新语句可以被移动到高优先级队列。但是，在它被移动之前，它之前的所有语句也必须被移动。这可能还需要2秒，因为每秒最多有100条语句被移动到高优先级队列。现在，当语句到达高优先级队列时，它前面可能有许多长时间运行的语句。在最坏的情况下，每一个语句都将被暂停，并且在从高优先级队列中检索下一个语句之前，每个语句都需要1秒钟的时间。因此，在这个场景中，在new语句开始执行之前需要222秒。

这个例子展示了应用程序的最坏情况。如何处理它取决于应用程序。如果应用程序对响应时间有很高的要求，那么它本身很可能会在更高的级别上限制用户。否则，它可以使用线程池配置参数来设置某种类型的最大等待时间。