简介面向数据库运维与性能测试人员的高并发优化实践资料聚焦MySQL线程池插件在现网性能瓶颈下的落地评估。内容围绕线程池工作原理、安装配置参数如thread_pool_size、thread_handling展开并给出完整的性能测试方案涵盖基准测试、压力测试、稳定性测试与负载测试四类策略配套人力与时间安排、测试环境搭建、测试数据准备及代码改造要点还对比了新增线程池前后单库与四库负载下的QPS、TPS、响应时间与资源利用率表现。资源包共1个PDF文件约3.26MB为一份结构完整的性能测试报告文档含文档修改记录、目录、网络拓扑与软硬件配置等章节便于按模块查阅复用。已有443人学习下载适合需要制定压测方案、评估线程池收益或排查高并发稳定性问题的中高级DBA与测试工程师参考。1. 线程池插件为什么加了线程反而更快一台 48 核的数据库服务器在 80 个并发请求下 TPS 跑到 13 万CPU 却只用了 68%把并发拉到 400TPS 翻到 25 万CPU 反而降到 67%。这个反直觉的现象正是 MySQL 线程池插件最值得琢磨的地方——按常理并发越高、线程越多上下文切换和锁竞争应该把 CPU 吃满才对可实测数据偏偏相反。原因在于 MySQL 默认的「一连接一线程」模型每个客户端连接都要 fork 一个 OS 线程高并发时线程创建销毁的开销、调度器的抢占、以及大量线程争抢同一把 LOCK_thread_count会把 CPU 时间大量消耗在「管理线程」而不是「执行 SQL」上。线程池插件把「连接」和「执行线程」解耦用固定数量的 worker 线程复用处理请求把线程管理的黑匣子成本压到最低。这份性能测试方案文档就是围绕「加插件前 vs 加插件后」的对照实验展开的从单库到四库、从负载到 12 小时稳定性把机制收益量化成了可复现的数字。搞懂它你才知道什么时候该开线程池、开了之后该盯哪些指标。2. 一连接一线程的代价线程创建销毁到底贵在哪2.1 默认模型下每个连接都背着一个 OS 线程MySQL 社区版默认的thread_handling是one-thread-per-connection。客户端连上来服务器就调用pthread_create起一个新线程连接断开再销毁。单看一次创建可能只有几十微秒但高并发场景下这个成本会被放大成两个层面的问题。第一层是内核态开销每次pthread_create都要分配内核栈、初始化调度实体、在task_struct里挂载销毁时再反向释放一遍这些动作全部发生在关键路径上。第二层是用户态竞争MySQL 内部维护一个全局线程计数和连接列表新线程注册、旧线程注销都要拿锁几百个线程同时进出时这把锁就成了隐形瓶颈。测试文档里「新增线程池前四个库负载测试」用 80 线程压出 129871 TPS、CPU 69%而「新增线程池后单库负载测试」用 400 线程压出 250274 TPS、CPU 67%——并发翻了 5 倍CPU 反而更低差额就是被省下来的线程管理开销。2.2 上下文切换与调度延迟的隐性成本线程数超过 CPU 核数后操作系统调度器要在大量可运行线程之间做时间片轮转。每次切换都要保存/恢复寄存器、刷新 TLB、可能还要跨核迁移缓存行这些动作对数据库这种缓存敏感型负载尤其致命。更麻烦的是「惊群」和「唤醒延迟」一个连接就绪事件到来时如果对应线程正在睡眠调度器要把它重新拉回运行队列这个延迟在几百线程规模下可以到毫秒级直接反映在 P99 响应时间上。线程池的做法是把「等待事件」和「执行任务」分离——少量 worker 线程常驻事件到达后投递到队列worker 取任务执行避免了「为每个连接维持一个随时可能被唤醒的线程」这种奢侈结构。常见的实现思路是维护一个任务队列加一组 workerworker 空闲时阻塞在队列上有新请求就唤醒一个处理完继续阻塞线程生命周期和连接生命周期彻底解耦。2.3 线程池插件的核心数据结构与调度逻辑线程池插件thread_pool在 MySQL 里以插件形式加载核心是thread_group数组。每个 group 有自己的监听线程listener、若干 worker 线程和一个任务队列。连接进来后先被分配到某个 grouplistener 负责从网络层收事件把「可读」的连接句柄塞进队列worker 从队列取连接、执行 SQL、把结果写回。关键参数有三个thread_pool_size决定 group 数量通常设成 CPU 核数thread_pool_stall_limit是「卡顿判定阈值」单位毫秒worker 处理一个任务超过这个时间listener 会认为它「卡住了」额外拉起一个 worker 来保证吞吐thread_pool_max_threads限制 worker 上限防止极端情况下无限膨胀。下面这段伪代码能说明调度骨架/* 简化后的线程池调度骨架非官方源码仅示意机制 */ void thread_group_listener(thread_group_t *group) { while (running) { /* 阻塞等待网络事件超时时间即 stall_limit */ event wait_for_event(group-connections, group-stall_limit); if (event TIMEOUT) { /* 有 worker 卡住太久补一个 worker 兜底 */ if (group-active_workers group-max_threads) continue; create_worker(group); } else { /* 把就绪连接投递到队列唤醒空闲 worker */ queue_push(group-task_queue, event.connection); wake_one_worker(group); } } } void worker_loop(thread_group_t *group) { while (running) { conn queue_pop_blocking(group-task_queue); /* 空闲时阻塞 */ execute_sql(conn); /* 真正干活 */ group-active_workers--; } }wait_for_event的超时值就是stall_limit它决定了「多久没进展就认为需要加人」。queue_push之后wake_one_worker只唤醒一个避免所有 worker 同时被惊醒来抢同一个任务。active_workers的增减是判断是否需要扩容的依据。这套结构把「线程数量」从「连接数量」里解放出来连接可以上千worker 始终维持在核数量级调度器压力骤降。3. 压测方案怎么设计从单库到四库的对照实验3.1 测试矩阵四个维度锁死变量这份文档的测试设计有一个很值得学的点它没有笼统地「开插件前后各压一次」而是拆成了 2×2 的矩阵——插件前/后 × 单库/四库再加一个稳定性维度和一个线程组数对比。单库和四库的区别在于连接分布单库是所有请求打到一个实例四库是分散到四个实例后者更接近分库分表的现网形态。为什么要分开测因为线程池的收益和「单实例上的连接密度」强相关四库场景下每个实例的连接数被摊薄收益曲线会不一样。测试目标里写得很明确CPU、内存使用率 ≤70%I/O wait ≤30%网络带宽 ≤70%90% 响应时间 ≤100ms成功率 ≥99.99%。这五个阈值不是拍脑袋而是给「什么时候停止加压」定了硬边界——一旦越界就停记录当前并发作为该配置下的容量上限。3.2 阶梯加压与停止条件测试步骤是标准的阶梯加压从 40 个请求流起步稳定跑 5 分钟再加 40再跑 5 分钟如此递推。每轮结束检查五个阈值全部满足才继续加任一不满足就停并定位问题。这个「5 分钟稳定期」很关键——短了测不出稳态长了浪费时间5 分钟足够让连接池、缓存、GC 进入稳定状态。找到最大能力对应的请求量后再用该量跑 5 分钟做「预防突发」验证。JMeter 的命令行执行方式也写进了文档./jmeter -n -t xxx.jmx -l logs/xxx.jtl跑脚本./jmeter -g logs/xxx.jtl -o report生成 HTML 报告。参数含义-n非 GUI 模式-t指定测试计划-l指定结果日志-g从已有 jtl 生成报告-o指定输出目录。这套流程的好处是可复现——同样的 jmx 和 jtl任何人跑出来结果一致。3.3 数据准备与代码改造的细节测试数据量给得很具体client_app20w、app_ability30w、ability_attr120w、conf_attr1w。为什么ability_attr要 120 万行因为查询语句是where pkid ? and attrcode ?走的是主键或唯一索引数据量太小会全部命中 buffer pool测不出真实 I/O 行为120 万行在 755G 内存的机器上刚好能让索引常驻、数据部分换出接近现网。代码改造只有一条把日志级别从默认调到error。这条看似不起眼实则血泪经验——如果日志还是info级别每次查询都写一行日志磁盘 I/O 和格式化开销会污染压测结果测出来的瓶颈可能是日志而不是数据库。参数化用的是 JMeter 的${__property(pkid)}和${__property(attrCode)}从属性文件读取保证每次请求参数不同避免缓存命中导致的虚高。4. 数据背后的机制TPS 翻倍与 CPU 不升反降4.1 四组数字的横向对比把文档里的实测结果拉成一张表机制收益一目了然场景并发线程TPS90% RTCPU成功率插件前·四库80129871≤1ms69%100%插件前·单库80131676≤1ms68%100%插件后·四库100171907≤1ms69%100%插件后·单库400250274≤2ms67%100%插件前80 线程基本就是天花板再加并发 CPU 就顶到 70% 红线插件后单库能扛到 400 线程TPS 从 13 万涨到 25 万接近翻倍而 CPU 还降了 1 个百分点。四库场景插件后只用了 100 线程就到 17 万 TPS说明四库的连接分散让单实例压力更小但总吞吐受限于压测机或网络没继续往上探。这组数据最反直觉的是「并发涨 5 倍、CPU 不涨」——如果还是默认模型400 线程光上下文切换就能把 CPU 吃满根本轮不到执行 SQL。4.2 为什么 CPU 没涨线程管理开销的消失用默认模型时CPU 时间大致分三块执行 SQL、线程调度、锁竞争。80 线程时调度占比还不大但已经能感觉到到 400 线程调度和锁竞争会吃掉相当比例导致「加并发不加吞吐」。线程池把 worker 固定在核数量级文档里提到 32 个组线程的配置调度开销基本恒定新增的并发只是让任务队列变长worker 一个接一个取任务CPU 几乎全部用于执行 SQL。所以 TPS 上去了、CPU 没上去不是玄学是省掉了「管理线程」这块隐性税。文档注释里还有一条细节某台服务器上其他应用常驻占用 3% CPU测试时要把这 3% 扣掉再看否则会误判线程池的 CPU 收益。4.3 稳定性测试12 小时 52 线程的观察稳定性用例用 52 线程持续跑 12 小时TPS 稳定在 95000 左右90% RT ≤1ms成功率 100%CPU 60%。52 这个数字不是随便选的它略高于「最优容量」对应的并发用来验证长时间运行下线程池不会因为任务堆积、worker 泄漏或队列膨胀而性能衰减。12 小时覆盖了业务高峰低谷的完整周期如果有内存泄漏或连接未归还这个时长足够暴露。结果 CPU 稳定在 60%没有爬升趋势说明 worker 复用没有引入资源泄漏。文档还记录了一个边界现象32 组线程单库、150 并发时 TPS 到 24 万、CPU 67%继续加并发 TPS 和 CPU 都不太涨但并发瞬间冲到 225、250 时CPU 反而掉到 60%。这个「掉 CPU」不是好事而是任务队列积压、worker 忙不过来、部分连接在排队等待实际有效吞吐已经到顶再加只是让队列更长。5. 避坑与排查线程池上线前必须知道的几件事5.1 现象开了线程池 TPS 反而下降原因通常是thread_pool_size设得过大或过小。设太大group 数量超过核数worker 之间又开始抢 CPU退化成默认模型设太小单 group 的队列成为瓶颈worker 忙不过来。解决从 CPU 核数起步压测时观察每个 group 的队列长度队列持续非空就适当加CPU 打满就减。5.2 现象短查询正常长查询把整个 group 拖死stall_limit默认值对 OLTP 短查询友好但遇到大查询或锁等待worker 卡住超过阈值listener 会不断补 worker直到thread_pool_max_threads上限然后新连接全部排队。解决把stall_limit按业务 P99 执行时间调大同时给长查询单独走连接池或限流别让它们和短查询混在一个 group。5.3 现象压测 TPS 很高现网一上就崩压测脚本参数化不足所有请求命中同一批热数据buffer pool 全命中测出来的是内存速度不是磁盘速度。解决参数化数据量至少覆盖索引基数的一个数量级文档里 120 万行对应 120 万种参数组合就是为了避免这种虚高。5.4 现象稳定性测试跑几小时后 RT 缓慢爬升常见原因是任务队列只增不减或者 worker 执行完没正确归还状态。排查时盯两个指标队列长度随时间的变化曲线、活跃 worker 数是否持续等于上限。如果队列单调上升说明消费速度跟不上生产要么加 worker要么查 SQL 是否变慢。5.5 现象CPU 利用率上不去但 TPS 也上不去不一定是线程池的问题可能是压测机先到瓶颈。文档用了 4 台 48 核压测机就是为了避免施压端成为短板。排查顺序先看压测机 CPU 和网络再看数据库网络带宽最后才怀疑线程池配置。文档里四库场景插件后只到 17 万 TPS 就停很可能就是压测端或网络先饱和。6. 设计取舍线程池不是银弹边界在哪线程池插件解决的是「高并发短查询下线程管理开销过大」这个特定问题它的收益有明确边界。第一它假设任务是短小的、可快速完成的如果业务里大量长查询、大事务worker 会被长期占用线程池退化成「少量线程排队」反而不如默认模型灵活。第二它把连接和执行解耦后连接数可以开得很大但每个连接仍占内存网络缓冲区、会话状态连接数无节制增长会把内存吃光所以max_connections该限还得限。第三stall_limit是个经验参数设小了频繁补线程、设大了卡顿发现不及时需要结合业务 RT 分布调没有万能值。第四线程池的收益在「单实例高连接密度」时最明显如果架构上已经做了分库分表、每个实例连接数本来就不高收益会打折扣——文档里四库场景插件后 100 线程就到 17 万 TPS继续加压受限于其他环节就是这个道理。验证线程池是否值得上我一般会做三件事先在测试环境用相同 jmx 跑插件前后对照看 TPS 和 CPU 的剪刀差再用performance_schema或show status like Threads_%观察线程创建速率是否下降最后跑一轮 12 小时稳定性确认没有队列堆积和内存爬升。这三步走完收益和风险基本就清楚了。从那以后我每次评估线程池配置都强制先跑一遍阶梯加压拿到容量曲线再决定thread_pool_size和stall_limit绝不拍脑袋填默认值。这份文档把测试矩阵、阈值、命令和实测数字都留了下来照着复现一遍比看十篇原理文章都管用。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/31 7:19:26 · 阅读 1.2k MySQL线程池插件性能实测：TPS翻倍与CPU不升反降的机制解析
简介面向数据库运维与性能测试人员的高并发优化实践资料聚焦MySQL线程池插件在现网性能瓶颈下的落地评估。内容围绕线程池工作原理、安装配置参数如thread_pool_size、thread_handling展开并给出完整的性能测试方案涵盖基准测试、压力测试、稳定性测试与负载测试四类策略配套人力与时间安排、测试环境搭建、测试数据准备及代码改造要点还对比了新增线程池前后单库与四库负载下的QPS、TPS、响应时间与资源利用率表现。资源包共1个PDF文件约3.26MB为一份结构完整的性能测试报告文档含文档修改记录、目录、网络拓扑与软硬件配置等章节便于按模块查阅复用。已有443人学习下载适合需要制定压测方案、评估线程池收益或排查高并发稳定性问题的中高级DBA与测试工程师参考。1. 线程池插件为什么加了线程反而更快一台 48 核的数据库服务器在 80 个并发请求下 TPS 跑到 13 万CPU 却只用了 68%把并发拉到 400TPS 翻到 25 万CPU 反而降到 67%。这个反直觉的现象正是 MySQL 线程池插件最值得琢磨的地方——按常理并发越高、线程越多上下文切换和锁竞争应该把 CPU 吃满才对可实测数据偏偏相反。原因在于 MySQL 默认的「一连接一线程」模型每个客户端连接都要 fork 一个 OS 线程高并发时线程创建销毁的开销、调度器的抢占、以及大量线程争抢同一把 LOCK_thread_count会把 CPU 时间大量消耗在「管理线程」而不是「执行 SQL」上。线程池插件把「连接」和「执行线程」解耦用固定数量的 worker 线程复用处理请求把线程管理的黑匣子成本压到最低。这份性能测试方案文档就是围绕「加插件前 vs 加插件后」的对照实验展开的从单库到四库、从负载到 12 小时稳定性把机制收益量化成了可复现的数字。搞懂它你才知道什么时候该开线程池、开了之后该盯哪些指标。2. 一连接一线程的代价线程创建销毁到底贵在哪2.1 默认模型下每个连接都背着一个 OS 线程MySQL 社区版默认的thread_handling是one-thread-per-connection。客户端连上来服务器就调用pthread_create起一个新线程连接断开再销毁。单看一次创建可能只有几十微秒但高并发场景下这个成本会被放大成两个层面的问题。第一层是内核态开销每次pthread_create都要分配内核栈、初始化调度实体、在task_struct里挂载销毁时再反向释放一遍这些动作全部发生在关键路径上。第二层是用户态竞争MySQL 内部维护一个全局线程计数和连接列表新线程注册、旧线程注销都要拿锁几百个线程同时进出时这把锁就成了隐形瓶颈。测试文档里「新增线程池前四个库负载测试」用 80 线程压出 129871 TPS、CPU 69%而「新增线程池后单库负载测试」用 400 线程压出 250274 TPS、CPU 67%——并发翻了 5 倍CPU 反而更低差额就是被省下来的线程管理开销。2.2 上下文切换与调度延迟的隐性成本线程数超过 CPU 核数后操作系统调度器要在大量可运行线程之间做时间片轮转。每次切换都要保存/恢复寄存器、刷新 TLB、可能还要跨核迁移缓存行这些动作对数据库这种缓存敏感型负载尤其致命。更麻烦的是「惊群」和「唤醒延迟」一个连接就绪事件到来时如果对应线程正在睡眠调度器要把它重新拉回运行队列这个延迟在几百线程规模下可以到毫秒级直接反映在 P99 响应时间上。线程池的做法是把「等待事件」和「执行任务」分离——少量 worker 线程常驻事件到达后投递到队列worker 取任务执行避免了「为每个连接维持一个随时可能被唤醒的线程」这种奢侈结构。常见的实现思路是维护一个任务队列加一组 workerworker 空闲时阻塞在队列上有新请求就唤醒一个处理完继续阻塞线程生命周期和连接生命周期彻底解耦。2.3 线程池插件的核心数据结构与调度逻辑线程池插件thread_pool在 MySQL 里以插件形式加载核心是thread_group数组。每个 group 有自己的监听线程listener、若干 worker 线程和一个任务队列。连接进来后先被分配到某个 grouplistener 负责从网络层收事件把「可读」的连接句柄塞进队列worker 从队列取连接、执行 SQL、把结果写回。关键参数有三个thread_pool_size决定 group 数量通常设成 CPU 核数thread_pool_stall_limit是「卡顿判定阈值」单位毫秒worker 处理一个任务超过这个时间listener 会认为它「卡住了」额外拉起一个 worker 来保证吞吐thread_pool_max_threads限制 worker 上限防止极端情况下无限膨胀。下面这段伪代码能说明调度骨架/* 简化后的线程池调度骨架非官方源码仅示意机制 */ void thread_group_listener(thread_group_t *group) { while (running) { /* 阻塞等待网络事件超时时间即 stall_limit */ event wait_for_event(group-connections, group-stall_limit); if (event TIMEOUT) { /* 有 worker 卡住太久补一个 worker 兜底 */ if (group-active_workers group-max_threads) continue; create_worker(group); } else { /* 把就绪连接投递到队列唤醒空闲 worker */ queue_push(group-task_queue, event.connection); wake_one_worker(group); } } } void worker_loop(thread_group_t *group) { while (running) { conn queue_pop_blocking(group-task_queue); /* 空闲时阻塞 */ execute_sql(conn); /* 真正干活 */ group-active_workers--; } }wait_for_event的超时值就是stall_limit它决定了「多久没进展就认为需要加人」。queue_push之后wake_one_worker只唤醒一个避免所有 worker 同时被惊醒来抢同一个任务。active_workers的增减是判断是否需要扩容的依据。这套结构把「线程数量」从「连接数量」里解放出来连接可以上千worker 始终维持在核数量级调度器压力骤降。3. 压测方案怎么设计从单库到四库的对照实验3.1 测试矩阵四个维度锁死变量这份文档的测试设计有一个很值得学的点它没有笼统地「开插件前后各压一次」而是拆成了 2×2 的矩阵——插件前/后 × 单库/四库再加一个稳定性维度和一个线程组数对比。单库和四库的区别在于连接分布单库是所有请求打到一个实例四库是分散到四个实例后者更接近分库分表的现网形态。为什么要分开测因为线程池的收益和「单实例上的连接密度」强相关四库场景下每个实例的连接数被摊薄收益曲线会不一样。测试目标里写得很明确CPU、内存使用率 ≤70%I/O wait ≤30%网络带宽 ≤70%90% 响应时间 ≤100ms成功率 ≥99.99%。这五个阈值不是拍脑袋而是给「什么时候停止加压」定了硬边界——一旦越界就停记录当前并发作为该配置下的容量上限。3.2 阶梯加压与停止条件测试步骤是标准的阶梯加压从 40 个请求流起步稳定跑 5 分钟再加 40再跑 5 分钟如此递推。每轮结束检查五个阈值全部满足才继续加任一不满足就停并定位问题。这个「5 分钟稳定期」很关键——短了测不出稳态长了浪费时间5 分钟足够让连接池、缓存、GC 进入稳定状态。找到最大能力对应的请求量后再用该量跑 5 分钟做「预防突发」验证。JMeter 的命令行执行方式也写进了文档./jmeter -n -t xxx.jmx -l logs/xxx.jtl跑脚本./jmeter -g logs/xxx.jtl -o report生成 HTML 报告。参数含义-n非 GUI 模式-t指定测试计划-l指定结果日志-g从已有 jtl 生成报告-o指定输出目录。这套流程的好处是可复现——同样的 jmx 和 jtl任何人跑出来结果一致。3.3 数据准备与代码改造的细节测试数据量给得很具体client_app20w、app_ability30w、ability_attr120w、conf_attr1w。为什么ability_attr要 120 万行因为查询语句是where pkid ? and attrcode ?走的是主键或唯一索引数据量太小会全部命中 buffer pool测不出真实 I/O 行为120 万行在 755G 内存的机器上刚好能让索引常驻、数据部分换出接近现网。代码改造只有一条把日志级别从默认调到error。这条看似不起眼实则血泪经验——如果日志还是info级别每次查询都写一行日志磁盘 I/O 和格式化开销会污染压测结果测出来的瓶颈可能是日志而不是数据库。参数化用的是 JMeter 的${__property(pkid)}和${__property(attrCode)}从属性文件读取保证每次请求参数不同避免缓存命中导致的虚高。4. 数据背后的机制TPS 翻倍与 CPU 不升反降4.1 四组数字的横向对比把文档里的实测结果拉成一张表机制收益一目了然场景并发线程TPS90% RTCPU成功率插件前·四库80129871≤1ms69%100%插件前·单库80131676≤1ms68%100%插件后·四库100171907≤1ms69%100%插件后·单库400250274≤2ms67%100%插件前80 线程基本就是天花板再加并发 CPU 就顶到 70% 红线插件后单库能扛到 400 线程TPS 从 13 万涨到 25 万接近翻倍而 CPU 还降了 1 个百分点。四库场景插件后只用了 100 线程就到 17 万 TPS说明四库的连接分散让单实例压力更小但总吞吐受限于压测机或网络没继续往上探。这组数据最反直觉的是「并发涨 5 倍、CPU 不涨」——如果还是默认模型400 线程光上下文切换就能把 CPU 吃满根本轮不到执行 SQL。4.2 为什么 CPU 没涨线程管理开销的消失用默认模型时CPU 时间大致分三块执行 SQL、线程调度、锁竞争。80 线程时调度占比还不大但已经能感觉到到 400 线程调度和锁竞争会吃掉相当比例导致「加并发不加吞吐」。线程池把 worker 固定在核数量级文档里提到 32 个组线程的配置调度开销基本恒定新增的并发只是让任务队列变长worker 一个接一个取任务CPU 几乎全部用于执行 SQL。所以 TPS 上去了、CPU 没上去不是玄学是省掉了「管理线程」这块隐性税。文档注释里还有一条细节某台服务器上其他应用常驻占用 3% CPU测试时要把这 3% 扣掉再看否则会误判线程池的 CPU 收益。4.3 稳定性测试12 小时 52 线程的观察稳定性用例用 52 线程持续跑 12 小时TPS 稳定在 95000 左右90% RT ≤1ms成功率 100%CPU 60%。52 这个数字不是随便选的它略高于「最优容量」对应的并发用来验证长时间运行下线程池不会因为任务堆积、worker 泄漏或队列膨胀而性能衰减。12 小时覆盖了业务高峰低谷的完整周期如果有内存泄漏或连接未归还这个时长足够暴露。结果 CPU 稳定在 60%没有爬升趋势说明 worker 复用没有引入资源泄漏。文档还记录了一个边界现象32 组线程单库、150 并发时 TPS 到 24 万、CPU 67%继续加并发 TPS 和 CPU 都不太涨但并发瞬间冲到 225、250 时CPU 反而掉到 60%。这个「掉 CPU」不是好事而是任务队列积压、worker 忙不过来、部分连接在排队等待实际有效吞吐已经到顶再加只是让队列更长。5. 避坑与排查线程池上线前必须知道的几件事5.1 现象开了线程池 TPS 反而下降原因通常是thread_pool_size设得过大或过小。设太大group 数量超过核数worker 之间又开始抢 CPU退化成默认模型设太小单 group 的队列成为瓶颈worker 忙不过来。解决从 CPU 核数起步压测时观察每个 group 的队列长度队列持续非空就适当加CPU 打满就减。5.2 现象短查询正常长查询把整个 group 拖死stall_limit默认值对 OLTP 短查询友好但遇到大查询或锁等待worker 卡住超过阈值listener 会不断补 worker直到thread_pool_max_threads上限然后新连接全部排队。解决把stall_limit按业务 P99 执行时间调大同时给长查询单独走连接池或限流别让它们和短查询混在一个 group。5.3 现象压测 TPS 很高现网一上就崩压测脚本参数化不足所有请求命中同一批热数据buffer pool 全命中测出来的是内存速度不是磁盘速度。解决参数化数据量至少覆盖索引基数的一个数量级文档里 120 万行对应 120 万种参数组合就是为了避免这种虚高。5.4 现象稳定性测试跑几小时后 RT 缓慢爬升常见原因是任务队列只增不减或者 worker 执行完没正确归还状态。排查时盯两个指标队列长度随时间的变化曲线、活跃 worker 数是否持续等于上限。如果队列单调上升说明消费速度跟不上生产要么加 worker要么查 SQL 是否变慢。5.5 现象CPU 利用率上不去但 TPS 也上不去不一定是线程池的问题可能是压测机先到瓶颈。文档用了 4 台 48 核压测机就是为了避免施压端成为短板。排查顺序先看压测机 CPU 和网络再看数据库网络带宽最后才怀疑线程池配置。文档里四库场景插件后只到 17 万 TPS 就停很可能就是压测端或网络先饱和。6. 设计取舍线程池不是银弹边界在哪线程池插件解决的是「高并发短查询下线程管理开销过大」这个特定问题它的收益有明确边界。第一它假设任务是短小的、可快速完成的如果业务里大量长查询、大事务worker 会被长期占用线程池退化成「少量线程排队」反而不如默认模型灵活。第二它把连接和执行解耦后连接数可以开得很大但每个连接仍占内存网络缓冲区、会话状态连接数无节制增长会把内存吃光所以max_connections该限还得限。第三stall_limit是个经验参数设小了频繁补线程、设大了卡顿发现不及时需要结合业务 RT 分布调没有万能值。第四线程池的收益在「单实例高连接密度」时最明显如果架构上已经做了分库分表、每个实例连接数本来就不高收益会打折扣——文档里四库场景插件后 100 线程就到 17 万 TPS继续加压受限于其他环节就是这个道理。验证线程池是否值得上我一般会做三件事先在测试环境用相同 jmx 跑插件前后对照看 TPS 和 CPU 的剪刀差再用performance_schema或show status like Threads_%观察线程创建速率是否下降最后跑一轮 12 小时稳定性确认没有队列堆积和内存爬升。这三步走完收益和风险基本就清楚了。从那以后我每次评估线程池配置都强制先跑一遍阶梯加压拿到容量曲线再决定thread_pool_size和stall_limit绝不拍脑袋填默认值。这份文档把测试矩阵、阈值、命令和实测数字都留了下来照着复现一遍比看十篇原理文章都管用。希望帮到你。本文还有配套的精品资源点击获取