尧图网页设计 
简介一份聚焦MySQL线程池插件性能测试的完整方案文档面向数据库管理员、运维工程师及性能测试人员。其背景是现网数据库在高并发下出现性能瓶颈文档围绕新增线程池插件前后的吞吐量、响应时间与稳定性展开对比梳理测试策略、测试方法、预估人力与时间安排适合作为内部压测落地的参照。资源为单个PDF文件大小约3.26MB目录结构完整包含测试计划、软硬件环境配置、测试数据与工具准备以及四库负载、单库负载、稳定性测试等多类型压测过程并预留结果分析框架。已有四百四十三人学习下载对于需要制定MySQL优化方案、准备性能测试报告或设计压测流程的团队可直接参考其中的步骤与风险点规避思路减少环境搭建和测试执行中的常见问题。整体条理清晰可按章节直接套用。1. 高并发下的 MySQL 线程池插件这份压测报告到底证明了什么现网数据库在高并发请求下出现性能问题这是一个比想象中更常见的故障场景连接数一上去CPU 先飙响应时间跟着抖业务方开始催DBA 开始背锅。这份资源就是当时团队针对MySQL 新增线程池插件能否缓解这个问题做的一整套性能测试报告覆盖线程池插件启用前后的四库/单库负载测试、12 小时稳定性测试和线程组数对比测试每个场景都记录了 TPS、90% 响应时间、CPU 使用率和网络流量消耗。它适合三类人准备引入线程池但拿不准收益的 DBA、需要写数据库压测方案的测试工程师、以及想搞懂线程池参数对性能影响的后端开发。下面按我拆这份报告的路径走一遍从原理到实测数据最后落到可复用的压测方法。2. 线程池插件的工作原理与参数配置2.1 高并发下线程创建销毁为什么成了瓶颈MySQL 传统的线程模型是一连接一线程one-thread-per-connection每个客户端连接对应一个独立线程。连接数少时这套模型简单直接但并发一旦上去问题就暴露了线程频繁创建销毁每次都要分配栈空间、做线程上下文切换这些开销消耗大量 CPU 时间片真正执行 SQL 的时间反而变少。更隐蔽的是当上千个线程同时处于可运行状态时操作系统要花大量时间在上下文切换上吞吐量可能出现断崖式下跌而不是缓慢下降。线程池插件的思路是把每来一个请求就建一个线程改成预先创建一组线程请求在队列里排队空闲线程领任务执行。这样有两个直接好处线程创建销毁的开销被摊平CPU 可以集中处理查询本身同时线程数量被限制在可控范围内不会出现线程数爆炸导致系统进入 thrashing 状态。值得注意的是线程池会尽量让同一个事务的 SQL 命中同一个线程组利用 MySQL 的连接亲和性减少线程间切换带来的缓存和事务状态丢失问题。这里要区分一个高频混淆点数据库连接池和 MySQL 线程池是两个不同层面的优化。连接池是应用侧复用 TCP 连接解决的是三次握手和建连开销线程池是 MySQL 服务端复用处理线程解决的是线程创建销毁和上下文切换。两者可以叠加使用一份性能报告里如果只给了应用连接池的数据不代表服务端线程模型就没有优化空间。2.2 三个核心参数thread_handling、thread_pool_size、thread_pool_stall_limit启用线程池最核心的配置是三个参数以 my.cnf 里的 [mysqld] 段为例[mysqld] thread_handling pool-of-threads thread_pool_size 32 thread_pool_stall_limit 500thread_handling 是总开关只有设为 pool-of-threads 才会走线程池模型不设置则维持默认的一连接一线程这个参数在运行时改成无效必须写进配置文件重启实例。thread_pool_size 定义线程组的数量线程组是线程池调度的基本单位每个组维护自己的任务队列。合理取值一般贴着 CPU 核数走但并不总是等于核数——文档里的测试环境是 48 核最终实测选用的就是 32 个组线程为什么不是 48后面第 6 章会单独说。thread_pool_stall_limit 是线程判定卡住的阈值单位毫秒。当某个线程组内的工作线程等待任务超过这个时间线程池会判定该组出现 stall然后动态创建一个新线程加入该组来救急。这个机制保证了线程池在突发流量下不会因为线程数固定而死等是线程池自适应能力的核心。默认值 500ms 一般不需要动线上如果出现明显的响应毛刺可以考虑适当调低让线程池更敏感地扩容。2.3 启用线程池的完整配置与验证方法落地到目标机器时我一般按三个步骤执行每一步都留验证手段避免配置写错把线上搞挂# 第一步备份原配置留后悔药 cp /etc/my.cnf /etc/my.cnf.bak.$(date %Y%m%d) # 第二步在 [mysqld] 段追加以下配置 # thread_handling pool-of-threads # thread_pool_size 32 # thread_pool_stall_limit 500 # 第三步重启 MySQL 实例 systemctl restart mysqld注意第二步的注释只是示意实际使用时要去掉 # 号并把参数值按机器配置填好。重启前建议先执行mysqld --validate-config做一次语法检查能拦截大部分手误。重启后验证线程池是否真正生效两条 SQL-- 验证线程池运行模式 SHOW VARIABLES LIKE thread_handling; -- 期望结果pool-of-threads -- 查看线程池运行时状态 SHOW GLOBAL STATUS LIKE Thread_pool%; -- 关注 Threadpool_threads已创建的线程数 -- 关注 Threadpool_running_threads正在执行任务的线程数如果 thread_handling 返回的还是 one-thread-per-connection大概率是配置写错了 section比如写到了 [client] 段或者拼写有差异。还有个坑MySQL 从 5.7 开始线程池在社区版二进制里是没有的需要商业版或者自己编译启用不同发行版对线程池的支持也各不相同。选型阶段就要先确认当前版本能不能用线程池否则压测做完了上线装不上白忙一场。3. 性能测试方案设计目标、数据与环境的准备3.1 测试目标拆解验证、探测、调优三件事一次做完一份压测方案如果只写压一下看多少 TPS那测完也说不清楚问题在哪。文档把目标拆成了三个层次这个拆法值得直接抄验证性是确认系统在指定并发下能稳定达到预期的最大处理能力探测性是摸接口和整个系统的负载压力承受边界也就是压到哪个点开始崩调优性是借压测暴露瓶颈比如 CPU 先到 70% 还是 I/O wait 先到 30%直接决定优化方向。对应的预期指标也写得很明确CPU、内存平均使用率不高于 70%系统 I/O wait 值不高于 30%网络带宽不超过 70%业务成功率不低于 99.99%90% 响应时间在 100ms 以内。这套指标的好处是每一条都能用监控工具直接量出来不存在模糊地带。压测过程中只要有一条不满足立刻停止加压转去定位而不是硬着头皮继续往上压——压测不是为了把系统打挂是为了找到它在什么位置开始不满足业务要求。3.2 测试数据准备四张基础表与参数化设计性能测试最怕用假数据压出假结论。文档在数据准备阶段给了明确的策略和基础数据量client_app20 万条app_ability30 万条ability_attr120 万条被测主表conf_attr1 万条测试脚本直接查 ability_attr 表查询条件用 pkid 和 attrcode 做参数化对应 Jmeter 里的${__property(pkid)}和${__property(attrCode)}两个参数引用。测试数据的量级按并发量和并发持续时间决定不是拍脑袋定的——数据量太小会导致所有查询都命中热数据压出来的性能虚高数据量太大又会让磁盘 IO 成为瓶颈掩盖线程池本身的效果。文档按现网最大请求体改造请求日志级别统一调整为 error这两点容易被忽略日志级别不改的话压测时大量 debug 日志输出会抢 CPU测出来的数据根本不能反映生产情况。3.3 软硬件环境与监控工具选型测试环境的规格从文档里的表可以直接读出MySQL 数据库单实例为 48 核 755G 内存负载机 4 台同为 48 核 755G 内存。这份报告的测试环境是高配机器读者如果要复现不必完全对齐配置但要保证负载机的性能高于被测数据库否则压测结果会被发压端卡住测出来的 TPS 是负载机的上限而不是数据库的上限。监控工具选了三件套施压端用 Jmeter 3.3系统监控用 Zabbix 做趋势记录JvisualVM 看 JVM 层面的资源消耗配合 Linux 命令top、iostat、vmstat实时定位瞬时瓶颈。我个人习惯在压测开始前 5 分钟就把监控开着记录 CPU、内存、I/O 的基线值压测结束再多记录 5 分钟观察回落情况。没有基线的性能数据很多时候没法判断一个资源占用率是压测引起的还是环境本身就有问题。4. Jmeter 压测执行从脚本编写到结果采集的完整步骤4.1 脚本编写JDBC 请求绑定参数化查询文档测试的是 ability_attr 表的查询接口这类场景在 Jmeter 里用 JDBC Request 最直接。新建线程组后在 Sampler 里添加 JDBC RequestSQL 语句按文档的表结构写select pkid, attrcode, attrname, attrvalue, date_format(create_time, %Y-%m-%d %H:%i:%s) as create_time, date_format(update_time, %Y-%m-%d %H:%i:%s) as update_time from ability_attr where pkid ${__property(pkid)} and attrcode ${__property(attrCode)}where 条件里的${__property(pkid)}是 Jmeter 的属性函数从外部参数文件读取值每一次请求都会取一个不同的参数组合避免所有请求都打在同一行数据上。参数化的意义在于模拟真实业务——真实用户查询的主键是分散的如果所有压测请求都命中同一条记录InnoDB 的缓冲池会把这条数据一直留在内存里压出来的查询耗时和真实场景完全不符。JDBC Request 里需要配置连接池信息JDBC Driver 选 com.mysql.jdbc.DriverDatabase URL 写成 jdbc:mysql://10.2.58.5:3306/库名Username 和 Password 按被测库填。注意 JDBC Request 里的连接数设置要和线程数匹配连接池大小小于线程数时部分线程会阻塞在拿连接上测出来的响应时间包含了等连接的排队时间需要把这份时间单独分开看。4.2 命令行压测与结果采集脚本在图形界面调通后压测执行阶段要用命令行模式跑把 Jmeter 的 GUI 资源占用问题隔离掉。文档给的执行命令是标准的非 GUI 压测流程# 进入 Jmeter 安装目录的 bin 目录 cd /usr/local/apache-jmeter-3.3/bin # 执行压测-n 非 GUI 模式-t 指定脚本-l 输出结果文件 ./jmeter -n -t query_ability_attr.jmx -l logs/result_$(date %Y%m%d_%H%M%S).jtl # 压测结束后生成 HTML 报告 ./jmeter -g logs/result_20220418_100000.jtl -o reports/html_20220418_100000参数说明-n表示非图形界面模式压测机上不弹窗适合长时间跑-t指定测试计划文件路径即.jmx后缀的脚本-l指定结果日志输出路径.jtl文件里每一行是一条请求的完整采样数据-g从已有的 jtl 文件生成图表报告-o指定 HTML 报告的输出目录要求该目录不存在或为空否则 Jmeter 会报错。生成的 HTML 报告会包含聚合报告、响应时间趋势图、TPS 趋势图和错误率图表可以直接下载到本地浏览器打开。这里有个注意点-l和-g用的 jtl 文件必须来自同一次压测混用不同轮次的数据生成的报告没有意义。另外.jtl文件默认只记录汇总数据要记录每个请求的完整响应信息需要勾选脚本里的 Save Response Data一般压测时不建议开会显著加大 IO 开销影响测试结果。4.3 分阶段加压策略40 个请求流递增法压测不是一上来就把并发拉满文档用的分阶段加压法很实用从模拟工具上发起 40 个请求流持续稳定运行 5 分钟确认各项指标都满足预期后再增加 40 个请求流再跑 5 分钟以此类推。判断是否继续加的标准就是第 3 章那套指标CPU 和内存平均使用率不高于 70%I/O wait 不高于 30%网络带宽不超过 70%成功率不低于 99.99%90% 响应时间在 100ms 以内。区间内全部满足重复加压任意一条不满足停止测试先定位问题再决定下一步。这个策略在工程上的价值在于它把找最大能力和找瓶颈点两个目标合在了一次压测里。每一次阶梯加压的过程都是一次数据采样最后画出来的 TPS 曲线会清楚显示拐点出现在哪一档并发下。还有一个容易漏的细节并发数增加到最大能力档位后文档要求用该档并发量再稳定运行 5 分钟目的是排除偶发抖动的影响。压测过程中如果出现 CPU 打满然后系统告警的情况不要只看 TPS 数字先查监控里是不是有内存溢出或者 IO 异常这些都会让数据失真。5. 结果解读与常见问题避坑三个最容易翻车的点5.1 线程池启用前后的关键数据对比把文档第 9 章的实测数据整理成对比表线程池的效果一目了然测试场景并发线程数TPS90% 响应时间CPU 使用率网络流量线程池前四库负载80129871≤1ms69%40.125MB线程池前单库负载80131676≤1ms68%41MB线程池后四库负载100171907≤1ms69%52.25MB线程池后单库负载400250274≤2ms67%75.125MB线程池后稳定性测试52约 95000≤1ms60%27.56MB这里有个关键细节线程池启用前并发只加到 80 就到顶了因为继续加并发 CPU 就会越过 70% 的红线线程池启用后单库场景能加到 400 并发TPS 从 131676 提升到 250274接近翻倍。而四库场景提升幅度相对小一些129871 到 171907约 32%原因是多库场景下可能还存在其他共享资源的竞争线程池解决的是线程调度层面的瓶颈不是所有瓶颈。单库场景 90% 响应时间从 1ms 变成 2ms这个变化也要留意线程池把大批请求阻塞排队后统一调度本质上是拿微小的延迟增加换取了吞吐量的成倍提升。对于以查询为主的业务系统2ms 的 90% 响应时间通常完全在可接受范围但如果业务对响应时间极度敏感这个 trade-off 需要在测试阶段就跟业务方确认清楚。5.2 稳定性测试12 小时持续运行看什么稳定性测试文档用的是 52 线程持续请求 12 小时观察的核心指标是TPS 能稳定在 95000 左右90% 响应时间保持在 1ms 以内CPU 使用率稳定在 60%无系统告警和内存溢出。这个场景模拟的是生产环境日常负载下系统的长期表现和负载测试有本质区别——负载测试看的是上限稳定性测试看的是不掉链子。持续运行 12 小时重点观察四个现象一是 TPS 是否出现缓慢下降的趋势如果有优先怀疑连接泄漏或缓存失效二是内存使用率是否随时间递增递增说明存在内存泄漏需要配合 JvisualVM 抓堆快照定位三是线程池是否频繁触发 stall 扩容机制如果 Threadpool_stall 相关的状态计数在持续增长说明线程池大小配置不够合理四是错误率是否为 0哪怕出现万分之一的偶发超时在 12 小时维度下都会被放大到不可接受。5.3 避坑记录三条血泪经验压测执行过程中最容易翻车的三个点都是实际踩过的坑一发压机先成了瓶颈压测数据失真。现象并发加到一定数值后 TPS 不再增长响应时间却开始上涨CPU 还没到 70%。原因负载机的 CPU 或网络带宽先被打满请求从负载机发出去就排队了数据库压根没收到全量压力。解决压测前先单独压负载机确认其上限能力或把请求流分散到多台负载机。文档用的是 4 台负载机单库场景 400 并发时明显是分散施压的这就是为了避免单台发压机的瓶颈。坑二只压一条 SQL漏掉了真实业务的 SQL 复杂度差异。现象压测报告数据很好看上了生产性能立刻拉胯。原因测试脚本只查了单表等值查询真实业务可能有 join、有范围查询、有 order by执行计划完全不同。解决从慢日志里捞 top N 的真实 SQL 作为压测脚本或至少分简单查询和复杂查询两组场景分别压。文档只压了 ability_attr 表的等值查询这决定了它的结论只能代表这类简单查询场景。坑三线程池参数抄默认值不按机器配置调。现象启用线程池后 TPS 反而下降了。原因thread_pool_size 设得过小线程组排队严重请求都在队列里干等。解决线程池大小先按 CPU 核数的 1/2 到 2/3 起步压测后基于 TPS 曲线做二次调整。文档的 48 核机器最终选 32 个组线程不是拍脑袋定的是通过对比测试观测不同组数下的 TPS 和 CPU 利用率后选出来的。6. 进阶线程组数对比测试与生产容量回推6.1 线程组数怎么选32 组线程的实测依据文档末尾有一段容易被忽略的补充测试新增线程池、32 个组线程配置下单库 150 并发5 台发压机从 10 逐渐增加到 50 并发时 TPS 达到 240000、CPU 使用率 67%继续增加并发数TPS 和 CPU 使用率升高不明显但并发数瞬间达到 225、250 时CPU 使用率反而降到了 60%。这个并发升高但 CPU 使用率下降的现象很有分析价值CPU 使用率下降有两种可能的解释——一是请求没有真正到达数据库被负载机或中间层挡住了二是线程池达到饱和后新请求在队列里等待线程数没有增加所以 CPU 不需要处理更多任务。文档的 48 核机器没有选择把线程组设成 48而是选了 32说明组数不是越多越好。线程组过少会导致队列排队严重过多则线程间调度开销增大。对多数实例来说从核数的 2/3 起步做对比测试比直接抄网上的默认值靠谱得多。6.2 压测结果如何回推生产容量规划压测报告不能停在TPS 是多少这个层面要落到生产环境能扛多少。我的习惯算法是先估算生产环境的峰值 TPS参考业务入口的历史监控数据取最近 30 天的最大值再留 30% 缓冲然后看测试环境的硬件规格和生产是否一致如果不一致需要做线性折算比如测试环境 48 核生产环境 96 核理论上限翻倍但实际受锁竞争和数据量分布影响按 1.5 倍估算更稳妥最后考虑数据量增长因素——文档测试环境 ability_attr 表有 120 万行如果生产这张表已经上亿随着数据量增长查询耗时也会增加容量规划时要预留足够的余量。每次压测完我都会强制走一遍固定动作确认 thread_handling 处于 pool-of-threads、核对 Threadpool 状态变量的计数分布、把当次压测的 jtl 文件和 my.cnf 配置归档到同一目录。这份 MySQL 线程池压测报告的完整流程和测试数据建议收藏一份作为基线参考下次遇到高并发性能问题时可以直接对照它的测试方案设计自己的验证场景。希望帮到你。本文还有配套的精品资源点击获取 高并发下的MySQL线程池插件：原理、压测与性能对比
简介一份聚焦MySQL线程池插件性能测试的完整方案文档面向数据库管理员、运维工程师及性能测试人员。其背景是现网数据库在高并发下出现性能瓶颈文档围绕新增线程池插件前后的吞吐量、响应时间与稳定性展开对比梳理测试策略、测试方法、预估人力与时间安排适合作为内部压测落地的参照。资源为单个PDF文件大小约3.26MB目录结构完整包含测试计划、软硬件环境配置、测试数据与工具准备以及四库负载、单库负载、稳定性测试等多类型压测过程并预留结果分析框架。已有四百四十三人学习下载对于需要制定MySQL优化方案、准备性能测试报告或设计压测流程的团队可直接参考其中的步骤与风险点规避思路减少环境搭建和测试执行中的常见问题。整体条理清晰可按章节直接套用。1. 高并发下的 MySQL 线程池插件这份压测报告到底证明了什么现网数据库在高并发请求下出现性能问题这是一个比想象中更常见的故障场景连接数一上去CPU 先飙响应时间跟着抖业务方开始催DBA 开始背锅。这份资源就是当时团队针对MySQL 新增线程池插件能否缓解这个问题做的一整套性能测试报告覆盖线程池插件启用前后的四库/单库负载测试、12 小时稳定性测试和线程组数对比测试每个场景都记录了 TPS、90% 响应时间、CPU 使用率和网络流量消耗。它适合三类人准备引入线程池但拿不准收益的 DBA、需要写数据库压测方案的测试工程师、以及想搞懂线程池参数对性能影响的后端开发。下面按我拆这份报告的路径走一遍从原理到实测数据最后落到可复用的压测方法。2. 线程池插件的工作原理与参数配置2.1 高并发下线程创建销毁为什么成了瓶颈MySQL 传统的线程模型是一连接一线程one-thread-per-connection每个客户端连接对应一个独立线程。连接数少时这套模型简单直接但并发一旦上去问题就暴露了线程频繁创建销毁每次都要分配栈空间、做线程上下文切换这些开销消耗大量 CPU 时间片真正执行 SQL 的时间反而变少。更隐蔽的是当上千个线程同时处于可运行状态时操作系统要花大量时间在上下文切换上吞吐量可能出现断崖式下跌而不是缓慢下降。线程池插件的思路是把每来一个请求就建一个线程改成预先创建一组线程请求在队列里排队空闲线程领任务执行。这样有两个直接好处线程创建销毁的开销被摊平CPU 可以集中处理查询本身同时线程数量被限制在可控范围内不会出现线程数爆炸导致系统进入 thrashing 状态。值得注意的是线程池会尽量让同一个事务的 SQL 命中同一个线程组利用 MySQL 的连接亲和性减少线程间切换带来的缓存和事务状态丢失问题。这里要区分一个高频混淆点数据库连接池和 MySQL 线程池是两个不同层面的优化。连接池是应用侧复用 TCP 连接解决的是三次握手和建连开销线程池是 MySQL 服务端复用处理线程解决的是线程创建销毁和上下文切换。两者可以叠加使用一份性能报告里如果只给了应用连接池的数据不代表服务端线程模型就没有优化空间。2.2 三个核心参数thread_handling、thread_pool_size、thread_pool_stall_limit启用线程池最核心的配置是三个参数以 my.cnf 里的 [mysqld] 段为例[mysqld] thread_handling pool-of-threads thread_pool_size 32 thread_pool_stall_limit 500thread_handling 是总开关只有设为 pool-of-threads 才会走线程池模型不设置则维持默认的一连接一线程这个参数在运行时改成无效必须写进配置文件重启实例。thread_pool_size 定义线程组的数量线程组是线程池调度的基本单位每个组维护自己的任务队列。合理取值一般贴着 CPU 核数走但并不总是等于核数——文档里的测试环境是 48 核最终实测选用的就是 32 个组线程为什么不是 48后面第 6 章会单独说。thread_pool_stall_limit 是线程判定卡住的阈值单位毫秒。当某个线程组内的工作线程等待任务超过这个时间线程池会判定该组出现 stall然后动态创建一个新线程加入该组来救急。这个机制保证了线程池在突发流量下不会因为线程数固定而死等是线程池自适应能力的核心。默认值 500ms 一般不需要动线上如果出现明显的响应毛刺可以考虑适当调低让线程池更敏感地扩容。2.3 启用线程池的完整配置与验证方法落地到目标机器时我一般按三个步骤执行每一步都留验证手段避免配置写错把线上搞挂# 第一步备份原配置留后悔药 cp /etc/my.cnf /etc/my.cnf.bak.$(date %Y%m%d) # 第二步在 [mysqld] 段追加以下配置 # thread_handling pool-of-threads # thread_pool_size 32 # thread_pool_stall_limit 500 # 第三步重启 MySQL 实例 systemctl restart mysqld注意第二步的注释只是示意实际使用时要去掉 # 号并把参数值按机器配置填好。重启前建议先执行mysqld --validate-config做一次语法检查能拦截大部分手误。重启后验证线程池是否真正生效两条 SQL-- 验证线程池运行模式 SHOW VARIABLES LIKE thread_handling; -- 期望结果pool-of-threads -- 查看线程池运行时状态 SHOW GLOBAL STATUS LIKE Thread_pool%; -- 关注 Threadpool_threads已创建的线程数 -- 关注 Threadpool_running_threads正在执行任务的线程数如果 thread_handling 返回的还是 one-thread-per-connection大概率是配置写错了 section比如写到了 [client] 段或者拼写有差异。还有个坑MySQL 从 5.7 开始线程池在社区版二进制里是没有的需要商业版或者自己编译启用不同发行版对线程池的支持也各不相同。选型阶段就要先确认当前版本能不能用线程池否则压测做完了上线装不上白忙一场。3. 性能测试方案设计目标、数据与环境的准备3.1 测试目标拆解验证、探测、调优三件事一次做完一份压测方案如果只写压一下看多少 TPS那测完也说不清楚问题在哪。文档把目标拆成了三个层次这个拆法值得直接抄验证性是确认系统在指定并发下能稳定达到预期的最大处理能力探测性是摸接口和整个系统的负载压力承受边界也就是压到哪个点开始崩调优性是借压测暴露瓶颈比如 CPU 先到 70% 还是 I/O wait 先到 30%直接决定优化方向。对应的预期指标也写得很明确CPU、内存平均使用率不高于 70%系统 I/O wait 值不高于 30%网络带宽不超过 70%业务成功率不低于 99.99%90% 响应时间在 100ms 以内。这套指标的好处是每一条都能用监控工具直接量出来不存在模糊地带。压测过程中只要有一条不满足立刻停止加压转去定位而不是硬着头皮继续往上压——压测不是为了把系统打挂是为了找到它在什么位置开始不满足业务要求。3.2 测试数据准备四张基础表与参数化设计性能测试最怕用假数据压出假结论。文档在数据准备阶段给了明确的策略和基础数据量client_app20 万条app_ability30 万条ability_attr120 万条被测主表conf_attr1 万条测试脚本直接查 ability_attr 表查询条件用 pkid 和 attrcode 做参数化对应 Jmeter 里的${__property(pkid)}和${__property(attrCode)}两个参数引用。测试数据的量级按并发量和并发持续时间决定不是拍脑袋定的——数据量太小会导致所有查询都命中热数据压出来的性能虚高数据量太大又会让磁盘 IO 成为瓶颈掩盖线程池本身的效果。文档按现网最大请求体改造请求日志级别统一调整为 error这两点容易被忽略日志级别不改的话压测时大量 debug 日志输出会抢 CPU测出来的数据根本不能反映生产情况。3.3 软硬件环境与监控工具选型测试环境的规格从文档里的表可以直接读出MySQL 数据库单实例为 48 核 755G 内存负载机 4 台同为 48 核 755G 内存。这份报告的测试环境是高配机器读者如果要复现不必完全对齐配置但要保证负载机的性能高于被测数据库否则压测结果会被发压端卡住测出来的 TPS 是负载机的上限而不是数据库的上限。监控工具选了三件套施压端用 Jmeter 3.3系统监控用 Zabbix 做趋势记录JvisualVM 看 JVM 层面的资源消耗配合 Linux 命令top、iostat、vmstat实时定位瞬时瓶颈。我个人习惯在压测开始前 5 分钟就把监控开着记录 CPU、内存、I/O 的基线值压测结束再多记录 5 分钟观察回落情况。没有基线的性能数据很多时候没法判断一个资源占用率是压测引起的还是环境本身就有问题。4. Jmeter 压测执行从脚本编写到结果采集的完整步骤4.1 脚本编写JDBC 请求绑定参数化查询文档测试的是 ability_attr 表的查询接口这类场景在 Jmeter 里用 JDBC Request 最直接。新建线程组后在 Sampler 里添加 JDBC RequestSQL 语句按文档的表结构写select pkid, attrcode, attrname, attrvalue, date_format(create_time, %Y-%m-%d %H:%i:%s) as create_time, date_format(update_time, %Y-%m-%d %H:%i:%s) as update_time from ability_attr where pkid ${__property(pkid)} and attrcode ${__property(attrCode)}where 条件里的${__property(pkid)}是 Jmeter 的属性函数从外部参数文件读取值每一次请求都会取一个不同的参数组合避免所有请求都打在同一行数据上。参数化的意义在于模拟真实业务——真实用户查询的主键是分散的如果所有压测请求都命中同一条记录InnoDB 的缓冲池会把这条数据一直留在内存里压出来的查询耗时和真实场景完全不符。JDBC Request 里需要配置连接池信息JDBC Driver 选 com.mysql.jdbc.DriverDatabase URL 写成 jdbc:mysql://10.2.58.5:3306/库名Username 和 Password 按被测库填。注意 JDBC Request 里的连接数设置要和线程数匹配连接池大小小于线程数时部分线程会阻塞在拿连接上测出来的响应时间包含了等连接的排队时间需要把这份时间单独分开看。4.2 命令行压测与结果采集脚本在图形界面调通后压测执行阶段要用命令行模式跑把 Jmeter 的 GUI 资源占用问题隔离掉。文档给的执行命令是标准的非 GUI 压测流程# 进入 Jmeter 安装目录的 bin 目录 cd /usr/local/apache-jmeter-3.3/bin # 执行压测-n 非 GUI 模式-t 指定脚本-l 输出结果文件 ./jmeter -n -t query_ability_attr.jmx -l logs/result_$(date %Y%m%d_%H%M%S).jtl # 压测结束后生成 HTML 报告 ./jmeter -g logs/result_20220418_100000.jtl -o reports/html_20220418_100000参数说明-n表示非图形界面模式压测机上不弹窗适合长时间跑-t指定测试计划文件路径即.jmx后缀的脚本-l指定结果日志输出路径.jtl文件里每一行是一条请求的完整采样数据-g从已有的 jtl 文件生成图表报告-o指定 HTML 报告的输出目录要求该目录不存在或为空否则 Jmeter 会报错。生成的 HTML 报告会包含聚合报告、响应时间趋势图、TPS 趋势图和错误率图表可以直接下载到本地浏览器打开。这里有个注意点-l和-g用的 jtl 文件必须来自同一次压测混用不同轮次的数据生成的报告没有意义。另外.jtl文件默认只记录汇总数据要记录每个请求的完整响应信息需要勾选脚本里的 Save Response Data一般压测时不建议开会显著加大 IO 开销影响测试结果。4.3 分阶段加压策略40 个请求流递增法压测不是一上来就把并发拉满文档用的分阶段加压法很实用从模拟工具上发起 40 个请求流持续稳定运行 5 分钟确认各项指标都满足预期后再增加 40 个请求流再跑 5 分钟以此类推。判断是否继续加的标准就是第 3 章那套指标CPU 和内存平均使用率不高于 70%I/O wait 不高于 30%网络带宽不超过 70%成功率不低于 99.99%90% 响应时间在 100ms 以内。区间内全部满足重复加压任意一条不满足停止测试先定位问题再决定下一步。这个策略在工程上的价值在于它把找最大能力和找瓶颈点两个目标合在了一次压测里。每一次阶梯加压的过程都是一次数据采样最后画出来的 TPS 曲线会清楚显示拐点出现在哪一档并发下。还有一个容易漏的细节并发数增加到最大能力档位后文档要求用该档并发量再稳定运行 5 分钟目的是排除偶发抖动的影响。压测过程中如果出现 CPU 打满然后系统告警的情况不要只看 TPS 数字先查监控里是不是有内存溢出或者 IO 异常这些都会让数据失真。5. 结果解读与常见问题避坑三个最容易翻车的点5.1 线程池启用前后的关键数据对比把文档第 9 章的实测数据整理成对比表线程池的效果一目了然测试场景并发线程数TPS90% 响应时间CPU 使用率网络流量线程池前四库负载80129871≤1ms69%40.125MB线程池前单库负载80131676≤1ms68%41MB线程池后四库负载100171907≤1ms69%52.25MB线程池后单库负载400250274≤2ms67%75.125MB线程池后稳定性测试52约 95000≤1ms60%27.56MB这里有个关键细节线程池启用前并发只加到 80 就到顶了因为继续加并发 CPU 就会越过 70% 的红线线程池启用后单库场景能加到 400 并发TPS 从 131676 提升到 250274接近翻倍。而四库场景提升幅度相对小一些129871 到 171907约 32%原因是多库场景下可能还存在其他共享资源的竞争线程池解决的是线程调度层面的瓶颈不是所有瓶颈。单库场景 90% 响应时间从 1ms 变成 2ms这个变化也要留意线程池把大批请求阻塞排队后统一调度本质上是拿微小的延迟增加换取了吞吐量的成倍提升。对于以查询为主的业务系统2ms 的 90% 响应时间通常完全在可接受范围但如果业务对响应时间极度敏感这个 trade-off 需要在测试阶段就跟业务方确认清楚。5.2 稳定性测试12 小时持续运行看什么稳定性测试文档用的是 52 线程持续请求 12 小时观察的核心指标是TPS 能稳定在 95000 左右90% 响应时间保持在 1ms 以内CPU 使用率稳定在 60%无系统告警和内存溢出。这个场景模拟的是生产环境日常负载下系统的长期表现和负载测试有本质区别——负载测试看的是上限稳定性测试看的是不掉链子。持续运行 12 小时重点观察四个现象一是 TPS 是否出现缓慢下降的趋势如果有优先怀疑连接泄漏或缓存失效二是内存使用率是否随时间递增递增说明存在内存泄漏需要配合 JvisualVM 抓堆快照定位三是线程池是否频繁触发 stall 扩容机制如果 Threadpool_stall 相关的状态计数在持续增长说明线程池大小配置不够合理四是错误率是否为 0哪怕出现万分之一的偶发超时在 12 小时维度下都会被放大到不可接受。5.3 避坑记录三条血泪经验压测执行过程中最容易翻车的三个点都是实际踩过的坑一发压机先成了瓶颈压测数据失真。现象并发加到一定数值后 TPS 不再增长响应时间却开始上涨CPU 还没到 70%。原因负载机的 CPU 或网络带宽先被打满请求从负载机发出去就排队了数据库压根没收到全量压力。解决压测前先单独压负载机确认其上限能力或把请求流分散到多台负载机。文档用的是 4 台负载机单库场景 400 并发时明显是分散施压的这就是为了避免单台发压机的瓶颈。坑二只压一条 SQL漏掉了真实业务的 SQL 复杂度差异。现象压测报告数据很好看上了生产性能立刻拉胯。原因测试脚本只查了单表等值查询真实业务可能有 join、有范围查询、有 order by执行计划完全不同。解决从慢日志里捞 top N 的真实 SQL 作为压测脚本或至少分简单查询和复杂查询两组场景分别压。文档只压了 ability_attr 表的等值查询这决定了它的结论只能代表这类简单查询场景。坑三线程池参数抄默认值不按机器配置调。现象启用线程池后 TPS 反而下降了。原因thread_pool_size 设得过小线程组排队严重请求都在队列里干等。解决线程池大小先按 CPU 核数的 1/2 到 2/3 起步压测后基于 TPS 曲线做二次调整。文档的 48 核机器最终选 32 个组线程不是拍脑袋定的是通过对比测试观测不同组数下的 TPS 和 CPU 利用率后选出来的。6. 进阶线程组数对比测试与生产容量回推6.1 线程组数怎么选32 组线程的实测依据文档末尾有一段容易被忽略的补充测试新增线程池、32 个组线程配置下单库 150 并发5 台发压机从 10 逐渐增加到 50 并发时 TPS 达到 240000、CPU 使用率 67%继续增加并发数TPS 和 CPU 使用率升高不明显但并发数瞬间达到 225、250 时CPU 使用率反而降到了 60%。这个并发升高但 CPU 使用率下降的现象很有分析价值CPU 使用率下降有两种可能的解释——一是请求没有真正到达数据库被负载机或中间层挡住了二是线程池达到饱和后新请求在队列里等待线程数没有增加所以 CPU 不需要处理更多任务。文档的 48 核机器没有选择把线程组设成 48而是选了 32说明组数不是越多越好。线程组过少会导致队列排队严重过多则线程间调度开销增大。对多数实例来说从核数的 2/3 起步做对比测试比直接抄网上的默认值靠谱得多。6.2 压测结果如何回推生产容量规划压测报告不能停在TPS 是多少这个层面要落到生产环境能扛多少。我的习惯算法是先估算生产环境的峰值 TPS参考业务入口的历史监控数据取最近 30 天的最大值再留 30% 缓冲然后看测试环境的硬件规格和生产是否一致如果不一致需要做线性折算比如测试环境 48 核生产环境 96 核理论上限翻倍但实际受锁竞争和数据量分布影响按 1.5 倍估算更稳妥最后考虑数据量增长因素——文档测试环境 ability_attr 表有 120 万行如果生产这张表已经上亿随着数据量增长查询耗时也会增加容量规划时要预留足够的余量。每次压测完我都会强制走一遍固定动作确认 thread_handling 处于 pool-of-threads、核对 Threadpool 状态变量的计数分布、把当次压测的 jtl 文件和 my.cnf 配置归档到同一目录。这份 MySQL 线程池压测报告的完整流程和测试数据建议收藏一份作为基线参考下次遇到高并发性能问题时可以直接对照它的测试方案设计自己的验证场景。希望帮到你。本文还有配套的精品资源点击获取