简介数据库性能测试报告模板/范文适合软件测试工程师、数据库管理员以及需要交付性能评估结论的项目团队。文档以完整报告结构梳理数据库性能测试的全流程依次涵盖计划概述、参考资料、术语解释、系统简介、测试环境、测试指标、测试工具与测试策略、测试数据收集、测试结果数据与截图、测试结论十个模块并给出了Jmeter指标和硬件指标的具体示例。资源为单个Word文档压缩包大小188KB结构清晰、可直接替换测试数据后复用。目前已有697人学习下载。借助该报告读者既能快速掌握数据库性能测试的开展思路和输出规范也能了解响应时间、吞吐量、CPU使用率、内存分页、磁盘I/O等关键指标的记录方法为后续定位性能瓶颈、提出索引优化与数据库配置调优建议提供明确参考。1. 数据库性能测试报告一份 doc 为什么比一屏截图更值钱凌晨两点被慢查询报警叫醒DBA 重启了数据库业务恢复了但第二天没人说得清瓶颈到底在哪——这是很多团队的真实状态。数据库性能测试报告.doc 要解决的不是“跑个压测截几张图”而是把一次压测变成团队能复用、能对照、能拍板的依据。它的价值在于环境记录、指标口径、结论建议都落在同一份文档里后续优化和容量规划有了基准线。这篇文章面向的是要自己动手做压测的开发、DBA 和运维。你会看到测试前要锁死哪些变量、压测场景怎么设、报告怎么组织才不吵架以及最容易让结果作废的坑。目标只有一个照着这份思路你也能产出让人信服的性能测试报告。2. 动笔写报告前先把这三件事锁死2.1 环境记录报告第一页必须是环境不是结果性能测试报告最容易翻车的地方不是压测过程而是环境描述不清楚。同一个压测脚本在 8C16G 和 32C64G 的实例上跑QPS 差三倍很正常。如果报告第一页不写清楚硬件规格、数据库版本、关键参数配置这份报告基本失去对比价值。我一般在报告的“测试环境”一节固定放这几项数据库版本含小版本号、实例规格CPU/内存/磁盘类型、操作系统版本、数据库关键参数buffer pool、连接数上限、日志大小、压测工具版本、压测机与数据库是否同机房。这些信息用一张表列出来复测时照着填就行。数据库参数这一项特别容易被忽略。很多人只写“用了默认配置”但默认配置在不同版本里差异很大。比如缓冲池大小默认值可能只有几百 MB压测时命中率上不去数据量和内存不匹配结果就是磁盘 IO 被打满延迟飙高。报告里至少要把缓冲池大小、最大连接数、日志落盘策略这三项写清楚。提示环境信息最好在压测开始前就记录而不是跑完之后补。补记的环境信息经常和实际不符尤其是参数被临时调过又改回去的情况。2.2 工具选型sysbench 与 pgbench 不是随便挑的压测工具选型直接决定报告的受众信不信。常见做法是MySQL 用 sysbenchPostgreSQL 用 pgbench需要模拟复杂业务负载时用 JMeter 或 HammerDB。工具选错最典型的例子是拿 sysbench 的默认 OLTP 脚本去测 PostgreSQL不是不能跑而是脚本里很多语法和语义跟 PostgreSQL 的事务模型对不上结果参考价值很低。sysbench 跑 MySQL 的最小命令长这样sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-userloadtest \ --mysql-passwordloadtest \ --mysql-dbperfdb \ --tables8 \ --table-size1000000 \ --threads16 \ --time300 \ --report-interval5 \ run这里--tables8和--table-size1000000控制数据总量8 张表、每表 100 万行约 800 万行数据属于中等规模。--threads16是并发连接数--time300表示压测持续 300 秒--report-interval5让工具每 5 秒输出一次实时统计方便后续和监控数据对齐。pgbench 这边初始化数据和执行压测是两步pgbench -i -s 100 -U loadtest -h 127.0.0.1 perfdb pgbench -c 32 -j 8 -T 300 -P 5 -U loadtest -h 127.0.0.1 perfdb-i是初始化模式-s 100表示数据规模系数为 100默认缩放系数 1 约 10 万行-s 100就是约 1000 万行。-c 32是模拟客户端数-j 8是线程数-T 300是持续时间 300 秒-P 5每 5 秒打印一次进度。注意-c和-j不相等时多个客户端会共享线程这个设置会影响结果报告里要写清楚。2.3 造数数据规模和分布决定了报告下限压测数据太少结果全在内存里跑磁盘 IO 体现不出来报告写出来偏乐观数据太多压测时间被初始化浪费产出比很低。我一般遵循两个原则数据量至少是内存缓冲池大小的 3 到 5 倍确保有一部分数据必然落到磁盘数据分布要贴合真实业务不能全是顺序主键插入后的均匀分布。造数时的常见坑是只关注行数不关注数据分布。真实业务里用户表常有热点数据比如 20% 的用户产生了 80% 的订单。压测数据如果完全均匀索引扫描和真实场景差异很大。sysbench 的默认脚本用随机主键访问效果还行自定义 SQL 压测时我会用 Python 脚本先造一份带倾斜分布的数据再灌入import random with open(orders.csv, w) as f: for user_id in range(1, 1000001): # 模拟热点用户20% 的用户产生 80% 的订单 if random.random() 0.8: order_count random.randint(1, 10) else: order_count random.randint(50, 200) for _ in range(order_count): f.write(f{user_id},{random.randint(1000, 9999)}\n)这段脚本的核心是random.random() 0.8这行判断它控制订单分布向少数用户倾斜。真实场景里的热点比例需要根据业务估算报告里也要注明数据分布假设否则结果很难迁移到生产环境。注意压测数据初始化完成后建议做一次备份或记录 checksum。后续如果重复压测发现数据被修改可以快速还原到初始状态避免结果对不上。3. 压测执行与监控采集数据可信报告才立得住3.1 场景设计单点查询、混合负载与慢查询探测报告里只有一张“QPS 多少、延迟多少”的总表是不够的读报告的人还想知道这套数据库在哪种负载下表现好在哪种负载下会崩。所以压测至少分三组场景只读场景、读写混合场景、写放大场景。每组场景单独出数据而不是混在一起给一个平均值。只读场景测的是索引和缓冲池的极限读写混合场景更接近 OLTP 真实比例写放大场景用来暴露磁盘瓶颈和锁竞争。常见做法是用 sysbench 的三个内置脚本oltp_read_only.lua、oltp_read_write.lua、oltp_write_only.lua每个场景跑 5 分钟。如果业务有典型 SQL比如按订单号查详情我会把这句 SQL 单独拎出来压测这样报告里能直接回答“这个查询能扛多少并发”。写放大场景经常暴露出配置问题。我遇到过某团队压测时只跑读写混合一切正常但一跑纯写场景延迟立刻从 5ms 涨到 200ms。原因是日志落盘策略是每次提交都刷盘纯写场景下刷盘频率飙升。这种问题只有分场景压测才能暴露混合负载的平均值会把它掩盖掉。3.2 并发梯度从低到高跑完才是完整曲线固定并发数压一次得出来的数据只能算抽样不能算测试。正确做法是跑并发梯度从 8、16、32、64 到 128逐级往上顶。每档跑 3 到 5 分钟记录该档下的 QPS、平均延迟、p95 延迟、p99 延迟和错误数。这样报告里就能看到性能曲线的拐点知道系统在哪个并发区间开始劣化。sysbench 跑并发梯度一般用循环脚本for threads in 8 16 32 64 128; do sysbench /usr/share/sysbench/oltp_read_write.lua \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-userloadtest \ --mysql-passwordloadtest \ --mysql-dbperfdb \ --tables8 \ --table-size1000000 \ --threads$threads \ --time180 \ --report-interval5 \ run result_${threads}.log done--time180是每档 3 分钟整个梯度跑完约 15 分钟。注意每档之间要留 10 到 20 秒的间隔让数据库的线程池和连接状态缓一缓避免上一档的余波影响下一档的数据。脚本跑完后每个result_${threads}.log文件里都有该并发下的 TPS、延迟和错误统计报告直接引用这些数据。并发梯度里最容易出错的是跳过中间档位。只跑 8 和 128 两个端点曲线看起来可能一直线性增长但真实情况可能是 64 时已经出现锁等待128 时延迟翻倍。没有中间数据这个劣化点就不会出现在报告里。3.3 监控采集压测机和监控数据要对上账压测工具自己输出的 QPS 和延迟只是应用视角的数据。报告里还需要数据库侧和系统侧的监控数据来交叉验证CPU 使用率、磁盘 IO 等待、连接数、锁等待时长。这三方数据对得上报告才有说服力对不上压测结果就可能受其他因素干扰。系统侧监控用mpstat和iostat就可以命令很简单mpstat -P ALL 5 mpstat.log iostat -x 5 iostat.log -P ALL按每个 CPU 核心输出5表示每 5 秒采样一次-x输出扩展统计含%util磁盘使用率。这两个命令在压测开始前启动压测结束后 kill采样周期和压测工具的--report-interval保持一致的 5 秒后续画时间轴时可以逐点对上。数据库侧的监控MySQL 用SHOW GLOBAL STATUS采样PostgreSQL 用pg_stat_database视图。有个细节容易被忽略压测工具的 TPS 是提交事务数数据库侧的Com_commit也是提交事务数两个数应该接近。如果差距超过 10%要检查压测机到数据库之间是否有连接池或代理层干扰了统计。进程级别监控平时边缘压测时很重要。pidstat -d 1能精确看到数据库进程的读写 IO当系统级 IO 指标正常但压测延迟偏高时进程级 IO 能快速定位到是不是某个后台进程在抢占资源。压测期间如果有备份任务或定时任务在跑报告里要特别标注否则下次复测时这些任务的时间对不上数据就不可比了。4. 报告结构把压测数据写成别人愿意照做的结论4.1 总览表先行结论放在第三屏以内数据库性能测试报告.doc 的阅读者通常是开发负责人或运维负责人他们没时间看完 40 页图表。报告开头放总览表包含每个场景在推荐并发下的 QPS、平均延迟、p95 延迟和结论达标 / 临界 / 不达标这样读者打开文档扫一眼就知道系统处于什么状态。总览表的行按场景分列按指标分。场景是只读、读写混合、写放大、慢查询探测指标是并发数、QPS、平均延迟、p95、错误率、结论。这里的“推荐并发”要说明是怎么定的一般取性能曲线拐点的前一档确保有 20% 到 30% 的余量。结论列不要写“性能良好”这种模糊词。要写具体判断QPS 达到目标的 120%p99 低于 100ms结论是达标p95 超过 200ms 且 CPU 未饱和结论是临界需要排查锁或配置。这样总览表本身就构成了报告最核心的交付物后面的章节是支撑它的证据。4.2 指标口径QPS、TPS、延迟口径不一致报告就是废纸同一个库里QPS 的定义至少有三种数据库每秒处理的请求数、压测工具每秒发出的事务数、监控系统统计的查询数。报告里不写口径后续任何对比都会变成扯皮你说 QPS 5000他说 QPS 8000其实两个数都不是同一个东西。我一般在报告里固定一套口径QPS 是数据库层统计的每秒查询数MySQL 用Questions状态值PostgreSQL 用pg_stat_database的xact_commit加xact_rollback估算TPS 是压测工具统计的每秒成功事务数延迟是压测工具端到端的响应时间包含网络开销。画时间轴曲线时官方状态值采样逻辑容易踩坑。MySQL 的SHOW GLOBAL STATUS是累计值要算 QPS 必须两次采样取差值除以时间间隔如果直接记录绝对值画图曲线一定是一条永远向上的斜线没有任何分析价值。我自己写过一个小的采样脚本提取每次采样的间隔增量mysql -uloadtest -ploadtest -h127.0.0.1 -N -e \ SHOW GLOBAL STATUS WHERE Variable_name IN (Questions,Com_commit,Threads_connected) \ snapshot_$(date %s).txt这个命令每 5 秒执行一次每次输出带时间戳的状态快照。后续用 Python 或 Excel 处理时把相邻两行的值相减再除以 5才是该时间点的真实速率。报告里注明“QPS 为两次采样间隔的增量平均值”口径就立住了。4.3 图表与附录放什么、不放什么报告里图表不贪多四类图足够并发梯度曲线图QPS 随并发变化的折线、延迟分布图平均/p95/p99 三条线、吞吐量随时间变化图、资源使用率与吞吐量叠加图。其他原始日志放附录正文只放加工后的数据和结论。并发梯度曲线图是报告里最重要的一张图。横轴是并发数纵轴是 QPS图上同时画平均延迟和 p99 延迟的次坐标。这张图能一次性回答“并发到了多少开始劣化”“当前系统的安全水位在哪”。有人喜欢用柱状图对比各档 QPS但柱状图看不出趋势走向不推荐。延迟分布图的坑在于怎么算百分位。sysbench 输出的百分位是“事件响应时间分布”不是每个请求的精确延迟排序。如果报告里要强调 p99建议用更细的采样数据自行计算。Python 算起来很快import numpy as np latencies [float(line.strip()) for line in open(latency.log)] p50 np.percentile(latencies, 50) p95 np.percentile(latencies, 95) p99 np.percentile(latencies, 99) print(fp50{p50:.2f}ms p95{p95:.2f}ms p99{p99:.2f}ms)latency.log里每行是一个请求的响应毫秒数来源于压测工具开启详细日志或从代理层抓取。强调一次p99 的计算样本量至少要上万否则尾延迟的统计意义不大。样本太少时 p99 会被几个偶发慢请求带偏报告里要注明样本量。4.4 结论与建议报告必须回答“然后呢”性能测试报告不是数据罗列最后一定要有明确的结论和建议。结论回答“这套数据库当前能不能扛住预期负载”建议回答“如果扛不住先调什么”。建议要按优先级排序第一条必须是投入产出比最高的动作一般是参数调整而不是加机器。常见建议排序数据库参数调优缓冲池大小、连接数上限、日志策略、索引优化新增或调整索引、SQL 改写减少全表扫描和回表、架构变更读写分离、分库分表。一份报告把建议写到第四级说明前三级已经试过且不够不能一上来就提分库分表。报告落款处要写测试时间、测试人、复测周期。性能测试报告是活文档数据库参数变更、版本升级、数据量翻倍后都要复测。复测时拿旧报告做基线对比才能看出变更到底是变好还是变坏。没有基线的新一轮压测只能算摸底不能算对比。5. 数据库性能测试避坑五个让报告作废的典型问题5.1 压测把业务打挂了环境隔离没做完现象压测进行到一半同一个数据库实例上的业务连接全部超时应用端报警最后只能紧急 kill 压测进程。原因压测直接打在共享实例上没有做环境隔离。压测流量和业务流量互相争抢连接数和 IO业务查询被挤到慢查询队列。解决压测必须使用独立实例或从库副本至少也要在业务低峰期执行并确认压测账号的连接数上限。压测前把实例规格、连接数、当前活跃会话数记录在报告的环境章节里。如果团队只有一套环境我一般会用容器起一个规格接近生产的独立实例压测完直接销毁避免污染业务数据。5.2 同一个场景两次跑出来数据差 30%缓存与数据分布没固定现象同一脚本、同一并发、同一时长第一次 QPS 12000第二次 QPS 8000差值明显到没法写报告。原因第一次压测前数据页已经在缓冲池里第二次压测时实例重启过缓冲池是冷的。或者压测数据被上一次压测修改过热点索引页分布发生了偏移。解决每次压测前做固定操作——重启实例清空缓冲池或者先跑一轮预热脚本把热点数据加载进缓冲池再开始计时。我一般选择预热方式因为生产环境不会总重启。预热脚本用只读场景跑 60 秒数据加载稳定后再记录正式数据并在报告里注明“已预热”。5.3 报告里 QPS 翻倍但业务延迟没变统计口径对不上现象报告里写 QPS 提升 100%但业务侧感知的响应时间毫无变化开发质疑压测结果造假。原因报告里对比的两个 QPS 来自不同口径。第一次是数据库层Questions状态算出来的第二次是压测工具的 TPS两者本身就差一个量级。解决全篇统一口径数据库层速率用状态值增量计算压测数据用工具结果两种数据分开列不混用。对比时只允许同口径数据做对比。报告的总览表里每个指标后面加一列“口径来源”比如“数据库层增量”或“压测工具统计”读者一眼能看明白。5.4 并发到 64 时异常掉底但监控一切正常连接数与线程池互锁现象并发从 32 升到 64 时QPS 不升反降数据库 CPU 才 40%磁盘 IO 也不忙监控数据看起来一切正常。原因应用层连接池上限是 50压测的 64 个线程里有 14 个在排队等连接或者数据库max_connections配置过小请求在连接建立阶段就超时了。解决压测并发数必须低于数据库连接数上限和压测机到数据库之间的连接池上限。压测前先确认三条链路应用连接池大小、数据库max_connections、压测工具线程数。三者取最小值为有效并发上限报告里要写明这个上限值。同时观察Threads_connected是否随并发线性增长如果增长停滞说明连接在哪一层被截住了。5.5 压测数据与监控画出的时间轴对不上窗口错位现象压测工具输出的 QPS 曲线峰值在 14:30:10但监控系统显示数据库负载峰值在 14:30:40查问题时空欢喜一场。原因监控系统的聚合粒度是 1 分钟压测工具采样是 5 秒峰值被分钟级聚合抹平了或者压测机与监控系统的时间不同步。解决压测前用 NTP 对齐所有机器的时间。监控采样粒度至少和压测工具一致取 5 秒或更细。取数时用同一条时间轴做对齐比如都取 14:30:00 到 14:30:05 这个窗口而不是一端取整点、一端取浮点时间。报告的曲线图统一用压测工具的时间戳为主轴监控数据按时间戳靠上去。6. 报告之外的进阶用法把性能测试报告变成容量规划的输入性能测试报告的终极用法不是归档而是变成容量规划的依据。当业务方问“双十一流量翻倍数据库扛不扛得住”答案不是拍脑袋而是翻出报告里的并发梯度数据做推算。把每个场景下的 QPS 和 CPU 使用率做成一张二维表横轴是并发数纵轴是 QPS 和 CPU%线性外推就能估算出目标流量下需要的资源。我把这套做法固化成了一张容量规划表放在报告附录里并发数、QPS、CPU%、磁盘 IO 使用率、连接数。下次业务提流量预测时按比例放大 QPS 目标从表里反查需要的并发数和资源规格。比如当前 32 并发下 QPS 6000、CPU 45%目标 QPS 12000按线性外推大约需要 64 并发CPU 预估到 90%就需要扩容或者优化 SQL。版本升级验收是另一个高价值场景。新版本数据库上线前用同一套压测脚本跑同一套数据和旧版本的报告做对比。对比时锁定三个变量数据量、并发数、压测时长。只要有一个变量变了对比就不成立。我一般把旧报告的数据放进一个新表跑完新版本后直接做差值差异超过 15% 的指标单独拉出来分析。关于报告自动化的习惯我每次压测完都会把原始日志和加工后的数据整理成统一命名的文件夹压测日期加场景名做前缀。下次复测直接复用同一套处理脚本单人 10 分钟就能从 raw data 更新到一份新报告。这个习惯帮我把报告产出时间从半天压缩到半小时也避免手工处理原始日志时算错百分位。自己第一次写性能测试报告时把精力和时间全花在跑数据上原始日志堆了几百兆最后报告里却只有三张截图被负责人问了几句“然后呢”就答不上来。后来才明白报告的价值在结论和建议不在数据全量展示。现在每当跑完一轮压测都会先问自己一个问题如果明天业务方拿着这份报告做容量决策信息够不够希望这篇文档也能帮到你少走一段为了压测而压测的弯路。本文还有配套的精品资源点击获取