简介一份针对MySQL高并发场景的线程池插件性能测试文档目标读者是数据库管理员、运维工程师及性能测试人员。文档从现网数据库的高并发性能瓶颈切入说明了线程池插件的工作原理、安装与配置参数并围绕新增线程池前后的性能稳定性对比给出完整的测试策略和执行方案覆盖基准测试、压力测试、稳定性测试与负载测试等类型同时包含测试环境准备、测试数据设计、代码改造建议、sysbench与JMeter工具使用以及人力资源和时间安排预估。压缩包内含单个PDF文件整体大小3.26MB内容预览显示其目录结构清晰从概述、术语、测试计划、测试目标、测试环境到新增线程池前四库与单库负载测试、新增线程池后四库与单库负载测试及稳定性测试便于按模块查阅。已有443人学习下载适合需要制定MySQL线程池优化验证方案、开展压测或参考性能测试报告模板的读者。1. 线程池插件在解什么题三个你迟早会撞上的故障现场MySQL 新增线程池插件这两年经常和数据库优化、性能压测一起出现在团队的改造清单里。我见过很多次这样的场景连接数从 200 爬到 800TPS 不是匀速下滑而是直接腰斩某个 3 秒的慢查询一出现整个实例的 P99 延迟立刻从 20ms 冲到 2 秒CPU 明明还有一半空闲新连接却进不来前端疯狂报超时。这三个现场如果只遇到一两次可能是偶然但反复出现时问题大概率不在 SQL 本身而在 MySQL 默认的“一个连接一个线程”调度模型上。线程池插件就是专门解决这类瓶颈的组件适合连接规模大、短事务密集、需要做性能压测来量化收益的线上实例也适合那些被连接风暴折腾过、想给数据库优化找到确定性方案的团队。2. MySQL 默认的连接模型为什么在并发下吃亏线程池原理与选型判断2.1 默认调度模型哪里贵一个连接一个线程的隐藏成本MySQL 默认情况下每个客户端连接对应一个服务端线程连接建立后线程常驻到连接断开。连接数少的时候这个模型很舒服没有排队、没有锁竞争连接状态全在自己线程栈上查起来也直白。但连接数一旦涨上去三笔开销会同时叠加。第一笔是线程数量的膨胀。每个线程默认有独立的栈空间连接池里几百个连接即使没在跑 SQL也占着线程资源更麻烦的是这些空闲线程会被系统调度器周期性唤醒主机 load 会虚高监控告警里经常能看到没业务的时候 CPU 的 sys 时间还在跳动。第二笔是上下文切换。大量线程在互斥锁和条件变量上等待每次切换都要保存和恢复寄存器还要刷新 CPU 缓存与 TLB。核数越多的机器跨核切换的成本越明显因为缓存热度全被打散了。第三笔最隐蔽慢查询放大。默认模型里一个慢查询占住一个线程表面上只影响它自己但当连接数上千、线程数上千时慢查询产生的锁等待和队列堆积会让其它线程一起陷入调度泥潭。我见过某团队排查了很久的“连接数一高全部变慢”问题最后发现根因就是默认模型把线程数量炒上去了跟具体 SQL 关系不大。2.2 线程池的核心设计解耦、排队与 stall 检测线程池插件的核心思想很简单把“连接”和“执行线程”解耦。连接仍然由独立的接收线程处理但收到 SQL 之后不直接执行而是放进线程组的任务队列一组 worker 线程从队列里取语句执行。这样连接数可以远远大于执行线程数线程总量被压在一个可控范围内。这里需要理解三个机制。第一个是线程组与队列。插件把 worker 分成若干组组数由 thread_pool_size 控制每组一个 FIFO 队列组内 worker 共享队列里的任务。第二个是 stall 检测如果 worker 执行一条语句的时间超过了 thread_pool_stall_limit插件会认为这个 worker “卡住了”会临时给组里补新线程来执行队列里的其它语句避免一个慢查询堵住后面所有快查询。第三个是事务感知的优先级事务中的语句会优先被调度执行完一个事务的语句后才会去取下一个任务避免长事务被短查询频繁打断。理解这三个机制后就知道线程池不是用来缩短 SQL 执行时间的。它省的是线程创建、上下文切换和调度损耗。如果瓶颈是磁盘 IO、行锁竞争或者慢 SQL 本身线程池救不了这点在选型时要想清楚。另外它和应用侧的连接池是两个层面的东西连接池管的是客户端复用 TCP 连接线程池管的是服务端复用执行线程两者配合使用不冲突。2.3 收益区间什么样的业务值得引入线程池我一般会用一个简单的判断标准Threads_connected 是否经常超过可用线程数。如果连接数长期在 50 以下线程池带来的收益非常有限甚至因为队列调度增加一点点延迟。真正值得上线程池的场景有三类。第一类是连接数经常 300 且短事务密集的业务比如订单写入、支付回调、API 数据查询。这类业务特点是单条 SQL 执行时间短但连接建立和线程切换的开销占比高。第二类是存在偶发慢查询的实例一个几十秒的全表扫描能把默认模型的调度彻底打乱线程池的 stall 检测可以把这个影响隔离在单个线程组内。第三类是有周期性连接风暴的场景比如活动秒杀、热点流量冲击连接数短时间内翻几倍线程池能让实例扛住连接建立的压力而不至于 OOM 或线程饥饿。不适合的场景也很明确实例本身连接数低、CPU 长期打满、瓶颈在计算或磁盘的先解决那几个问题再回来看线程池。纯 OLAP 的大查询场景也不太合适因为大查询本身就吃满线程排队意义不大。对照一下自己的业务形态再决定要不要投入这个方向比先装插件再找理由要高效得多。3. 把线程池插件装起来并验证生效从加载到最小压测命令3.1 确认插件文件与加载流程加载线程池插件前先确认插件文件是否存在。不同发行版对线程池的打包方式不太一样有的编译进了服务端内核没有独立插件文件有的是独立插件需要手动加载。我一般先做这一步mysql -uroot -p -e SHOW VARIABLES LIKE plugin_dir; ls -l /usr/lib/mysql/plugin/thread_pool.so第一行查出插件的存放目录第二行在系统层面确认 thread_pool.so 存在。如果文件找不到先检查安装包是不是完整版部分精简安装包会把插件单独拆分出去。确认文件存在后用 SQL 加载插件INSTALL PLUGIN thread_pool SONAME thread_pool.so;INSTALL PLUGIN 会把插件信息写入 mysql.plugin 表重启后依然生效这也是生产环境的常规做法。如果只是临时验证效果可以用 LOAD PLUGIN重启后失效。加载后验证是否真的启用SELECT PLUGIN_NAME, PLUGIN_STATUS, PLUGIN_TYPE FROM information_schema.PLUGINS WHERE PLUGIN_NAME thread_pool;看到 PLUGIN_STATUS 为 ACTIVE 说明加载成功。如果查出来是空的说明插件已被编译进服务端但名字不同或者当前版本根本不含线程池功能。卸载时用 UNINSTALL PLUGIN thread_pool 即可但卸载前要确认业务低峰因为连接调度模型会立即切换回默认模式。3.2 核心参数表与调节逻辑线程池插件需要关注的参数不多我按优先级整理了这张表参数作用常见默认建议起点thread_pool_size线程组数量16逻辑核数不要轻易翻倍thread_pool_stall_limitworker 卡顿阈值毫秒100先保持默认压测后再调thread_pool_max_unlimited_threads保留的无限制线程数4保持默认不要设为 0动态设置参数的命令如下SET GLOBAL thread_pool_size 16; SET GLOBAL thread_pool_stall_limit 100; SET GLOBAL thread_pool_max_unlimited_threads 4;这段 SQL 里每个参数都可以在线修改但要注意部分发行版对 thread_pool_size 是只读的必须写进 my.cnf 再重启实例。生产环境改线程池参数前先看机器逻辑核数。如果已经是 16 核thread_pool_size 从 16 开始压测后发现队列积压明显再尝试加到 32但每一档都要重新压测确认不能只看 TPS 峰值。提示不要一上来就把 thread_pool_size 设成核数的 2 倍线程组之间的锁竞争会放大抖动具体的翻车案例在第 5 章详细讲。3.3 最小验证一条 point_select 压测命令加载插件后先看两个全局状态值确认线程池真的在起作用mysql -uroot -p -e SHOW GLOBAL STATUS LIKE Threads_connected; SHOW GLOBAL STATUS LIKE Threads_running;Threads_connected 是当前连接数Threads_running 是正在执行 SQL 的线程数。默认模型下这两个值会非常接近线程池生效后Threads_running 会明显小于 Threads_connected。然后跑一条最小压测命令验证sysbench /usr/share/sysbench/oltp_point_select.lua \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-userbench --mysql-passwordbench \ --mysql-dbsbtest \ --tables8 --table-size1000000 \ --threads300 --time120 --report-interval10 \ --rand-typeuniform --warmup-time30 \ run这条命令里threads300 模拟 300 个连接同时发点查time120 表示统计时长 120 秒warmup-time30 让 buffer pool 先热起来这 30 秒不纳入统计report-interval10 每 10 秒输出一次中间结果方便观察 TPS 曲线有没有周期性塌陷。跑的同时另开一个终端每 5 秒采样一次 Threads_running。判断插件是否生效的标准很简单300 个连接下Threads_running 能稳定在 30 到 60 这个量级且 TPS 曲线平滑说明线程池的复用机制在工作。如果 Threads_running 跟着连接数一起涨到 200要么插件没生效要么参数配置有问题回到 3.1 重新检查。4. 数据库优化前的性能压测方案从基线采集到结论下发4.1 压测设计先基线、再对照、看趋势要聊详细测试方法第一步永远是设计对照实验而不是直接拿压测工具开跑。线程池压测最容易犯的错是插件已经加载了才想起没测基线只能凭印象说“好像变快了”。这种结论没法说服任何人。我通常把测试方案拆成五个步骤定并发梯度、定数据规模、定每轮时长、定轮间回收条件、重复取样取中位数。并发梯度建议 50 / 100 / 200 / 400 / 600 五档覆盖从低并发到连接风暴的区间。数据规模固定为 8 张表、每张 100 万行保证 buffer pool 能装下热数据避免 IO 干扰结果。每轮压测时长 300 秒起步预热 30 秒不计入统计。关键是轮间回收每轮结束后要等 Threads_connected 回到个位数再开下一轮否则上一轮的连接还挂在实例上会污染下一轮的基线。加载线程池插件前先完整跑一遍基线五档重启实例并加载插件后再按同样的参数跑一遍对照。每个档位至少重复两次取中位数而不是平均值因为平均值容易被一轮异常抖动拉偏。如果两轮结果差异超过 15%先检查压测机 CPU 是不是被打满了这是最常见的污染源。4.2 sysbench 命令模板从 prepare 到 run 的参数解读sysbench 是压测 MySQL 最常用的工具要先准备数据再开跑。数据准备命令sysbench /usr/share/sysbench/oltp_point_select.lua \ --mysql-host127.0.0.1 --mysql-userbench --mysql-passwordbench \ --mysql-dbsbtest --tables8 --table-size1000000 \ prepareprepare 会创建 sbtest 库和 8 张测试表每张灌入 100 万行随机数据。如果已经跑过一轮重复执行 prepare 会报表已存在先加 --mysql-ignore-errorson 或者手动 drop 掉旧表。混合读写场景用 oltp_read_write 脚本sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 --mysql-port3306 \ --mysql-userbench --mysql-passwordbench \ --mysql-dbsbtest \ --tables8 --table-size1000000 \ --threads400 --time300 --report-interval10 \ --rand-typeuniform --warmup-time30 \ --mysql-ignore-errorsall \ run关键参数的含义和调整建议参数作用建议--threads模拟并发连接数按梯度 50 到 600 调整--time统计时长秒300 起太短看不出长尾--report-interval中间结果输出间隔秒10方便观察时间趋势--warmup-time预热时长秒30让缓存和数据页热起来--mysql-ignore-errors屏蔽死锁等预期内错误压测时建议 all如果环境里没有 sysbench也可以用 MySQL 自带的 mysqlslap 做快速验证命令更简单但场景单调mysqlslap --host127.0.0.1 --userbench --passwordbench \ --concurrency200 --iterations3 \ --number-of-queries100000 \ --create-schemasbtest --querySELECT * FROM sbtest1 WHERE id RAND()*1000000;mysqlslap 的 --concurrency 是并发连接数--number-of-queries 是总查询数--iterations 是重复轮数。它适合快速确认线程池是否生效但因为它只跑单条查询不适合模拟真实业务的读写混合特征正式结论还是要用 sysbench。4.3 结果指标怎么读TPS、P95/P99 与 Threads_running 的组合压测结束不能只看 TPS那是最容易骗人的数字。我每次至少看这四个指标的组合指标来源说明TPSsysbench 输出整体吞吐看趋势看稳定性latency avgsysbench 输出平均延迟容易被长尾拉高latency p95 / p99sysbench 输出长尾指标线程池主要收益体现在这里Threads_runningSHOW GLOBAL STATUS同时执行 SQL 的线程数判断是否饱和判断逻辑分三种情况。第一种TPS 不降P95 明显下降Threads_running 远小于连接数这是线程池收益最明确的表现。第二种TPS 和延迟基本持平说明当前并发水平还没到默认模型的瓶颈区间线程池价值还没发挥出来需要把并发再往上拉。第三种TPS 下降且 Threads_running 打满核数说明瓶颈已经转移到锁、磁盘或 CPU 计算上这时候线程池救不了别在插件上继续调参浪费时间。看结果时要把 TPS 曲线和延迟分布放在同一条时间轴上对照。report-interval10 输出的中间数据可以直接看到哪段时间 TPS 塌陷、哪段时间 P99 飙高。如果塌陷是周期性的大概率是线程池队列或后台任务在捣乱如果是随机性的先怀疑压测机资源争用。4.4 一份可复用的测试记录表压测结论要能复查建议每轮都填一张固定格式的记录表。我用的模板如下轮次插件状态并发TPSavg(ms)p95(ms)p99(ms)Threads_running结论1未启用400185006.222.548.3388基线2已启用400192005.912.836.762收益明显填写时注意Threads_running 取压测稳定期的中位数不要取峰值TPS 取 sysbench 最终输出里的平均值同时记录 report-interval 里有没有异常波动。下结论的标准是同并发下 p99 下降超过 30%或者 TPS 提升超过 10%同时 Threads_running 明显下降才说明线程池真正生效。如果只有一两个档位符合收益标准建议把结论写成“并发 400 以上收益明显以下无差异”而不是笼统的“线程池有效”。这样后续容量规划、连接池参数调整都能有据可依。5. 线程池插件避坑指南5 个线上翻车场景与排查路径5.1 坑一压测到一半连接全部挂起SQL 既不执行也不报错现象并发 500 时 sysbench 突然卡住Threads_connected 一直涨Threads_running 只有个位数查询既不返回也不报错进程列表里大量连接的 Command 是空的状态。原因大概率是有人把 thread_pool_max_unlimited_threads 设成了 0。这个参数的本意是给管理连接保留几个不受线程池限制的线程设为 0 后一旦 worker 全忙新连接全部进入排队连管理员的连接都挤不进去。另一种可能是 thread_pool_stall_limit 被调成 10msworker 频繁判断自己“卡住”而不断重调度实际没有线程在执行队列里的任务。解决先用同机已建立的管理连接执行 SET GLOBAL thread_pool_max_unlimited_threads 4 恢复现场如果管理连接也进不去需要重启实例并先在 my.cnf 里改好。这个坑的教训是调参之前先搞清楚参数是“限制”还是“保留”不要想当然。5.2 坑二thread_pool_size 翻倍P95 反而变差现象某 16 核机器上把 thread_pool_size 从 16 改成 32TPS 没涨P95 从 20ms 涨到 60ms抖动明显加剧。原因线程组之间靠全局队列和锁分发任务组数翻倍后锁竞争和跨组调度开销被放大同时每个组都要维持自己的 worker 池空闲 worker 还在周期性唤醒白白消耗调度资源。解决thread_pool_size 从逻辑核数开始往上每档都要重新压测验证对比抖动率而不是只看峰值。我的习惯是同时记录 report-interval 输出的每一段 TPS 波动范围波动超过 20% 就说明参数过头了。宁愿组数偏少让队列稍微排队也不要盲目翻倍。5.3 坑三短事务点查场景开了线程池 TPS 反而掉 20%现象oltp_point_select 压测时启用线程池后 TPS 从 20000 掉到 16000团队一度怀疑插件有 bug。原因点查本来就是微秒级语句单条执行时间远低于 stall_limitworker 一直在“取语句、执行、取语句”循环线程池引入的队列和调度开销反而超过了它省下的线程创建开销。另一个叠加因素是压测时保持 autocommit0短查询也要等 commit 排队事务感知优先级把点查询人为拉长了。解决短事务场景先看 TPS 是否下降超过 20%如果下降明显把 stall_limit 恢复默认值 100并确认压测脚本用的是 autocommit 模式不要把事务显式包在 short query 外面。混合读写场景才是线程池收益最容易出现的区间点查结果只能作为参考。5.4 坑四通过 SHOW PROCESSLIST 看线程数误判线程池失效现象压测机明明在打 400 并发SHOW PROCESSLIST 里却只有不到 20 条 Query 记录团队认为线程池“吞了”SQL。原因线程池的 worker 在执行语句时对应的连接状态不一定显示为 Query很多实现里连接状态是复用的进程列表反映的是连接协议状态不是实际执行状态。拿着 PROCESSLIST 数 Query 来判断线程池是否工作方向就错了。解决切到 SHOW GLOBAL STATUS LIKE Threads_running 看实际执行数想看排队情况需要查 performance_schema 里与线程池相关的等待事件。不同发行版的监控表名不同先确认 performance_schema 的 statements 统计有没有开启再去找对应表不要在文档里猜名字。值得强调压测过程中所有采样都要用脚本自动执行不要手动敲命令否则采样频率跟不上。5.5 坑五压测并发只在 50~100得出“线程池无效”的错误结论现象A同学在 100 并发下跑了基线对比TPS 几乎一样输出结论是线程池没价值结果后来线上 500 并发的真实流量直接把实例打挂。原因线程池收益在“连接数远大于可用执行线程数”时才明显。100 并发在 8 核机器上默认 one-thread-per-connection 完全够用线程创建开销还远没到影响吞吐的程度对比结果当然无差异。解决压测梯度里必须包含超过临界值的档位。先用 Threads_connected 和 Threads_running 判断瓶颈区间当 Threads_connected 明显大于可用 worker 数且 Threads_running 已接近核数时才是线程池发挥价值的位置。建议梯度拉到 600 甚至 800把连接风暴的场景也覆盖进去否则很容易得出“无效”的正确结论但这个结论只适用于低并发区间。6. 让线程池收益可持续的验证习惯每次压测前先看这四个数线程池落地后不能只看一次压测报告就收工。我形成了一套固定的验证习惯每次上线前或参数调整后都先看四个数Threads_connected 与 Threads_running 的比值、排队语句的趋势、P95 与 avg 的倍数关系、压测机本身的 CPU 占用。第一个数Threads_connected 和 Threads_running 的比值如果小于 3:1说明连接数还没到线程池的发挥区间这时候对比插件开关没有意义。如果大于 10:1 且 Threads_running 依然被压得很低才能确认线程池的复用机制在起作用。第二个数是排队趋势。线程池内部排队很难直接看到我一般用 Threads_running 是否稳定和 TPS 曲线是否周期性塌陷来判断。稳定的 Threads_running 加上平滑的 TPS 曲线说明队列吞吐健康。第三个数是 P95 与 avg 的比值。正常情况下这个比值在 3 到 5 之间超过 5 说明延迟分布被长尾撕裂这时候看平均延迟毫无意义要回头找是不是有大查询在干预 stall 检测或者锁等待在堆积。第四个数最容易忽略压测机的 CPU。压测机被打满时压出来的所有指标都是假的TPS 上不去不是 MySQL 的瓶颈而是压测机到极限了。每轮压测前我都习惯在压测机上跑一个 top 看一眼CPU 超过 80% 就降并发或换更强的压测机。这套习惯帮我避开了很多次误判。最典型的一次是某跨平台系统压测时线程池参数已经对了但压测机 CPU 跑满P99 一直下不来团队差点把线程池又拆掉。我让压测机从 4 核临时扩到 8 核同样的参数下 P99 立刻降下来。从那以后我每次做数据库优化第一眼永远先看压测环境本身干不干净再看 MySQL 的指标。先看环境再看配置最后才下结论这个顺序希望能帮到你。本文还有配套的精品资源点击获取