YashanDB性能评估指南：6大核心指标与压测方法

YashanDB最近在国产基础软件圈子里存在感不低，厂商宣发材料里常出现“性能比肩国际主流数据库”这种话。但数据库选型这件事，光看PPT和跑分广告没有用，任何库到了手上都要先搭压测环境、把核心性能指标跑一遍，再决定能不能上生产。这篇文章就聊一聊我评估YashanDB性能时固定要看的6个重要指标——事务吞吐量、查询响应时间、并发连接处理能力、读写吞吐、资源利用率和稳定性，重点讲清楚每个指标怎么测、怎么看、有哪些测试时最容易踩的坑。不管你是正在做选型对比，还是已经引入YashanDB想验证真实水平，这份经验都适用。

1. 为什么性能评估不能只看跑分

1.1 数据库选型最大的坑：拿单一数字当救命稻草

很多项目组评估数据库时有一个共同的坏习惯：从网上找一个厂商公布的基准测试数字，看到TPS很高就直接下结论说“这个库很厉害”。实际上，厂商公布的数字是在特定硬件、特定配置、特定数据模型下跑出来的，跟你实际业务形态的匹配度可能非常低。

我举一个最典型的场景。假设有两个数据库A和B，跑同样的TPC-C模型，A的每秒事务数比B高出不少。看起来A更强，但把并发从100逐步升到500时，A的平均响应时间翻了20倍，B只翻了2倍。如果业务是高并发实时交易，B反而更合适；如果只是内部管理系统，并发压力不大，A确实有优势。这说明单一指标没有绝对意义，脱离业务场景谈性能等于空谈。

YashanDB这类企业级数据库通常面向的是一般OLTP在线交易、混合负载、核心系统长稳运行这三类业务。每一类业务要求的性能侧重点完全不同：交易系统最怕吞吐量高但响应时间抖，混合负载系统最怕资源和查询互相抢，7x24核心系统最怕跑着跑着性能突然掉一半。所以我才坚持用多个指标做联合评估，而不是盯着一张跑分榜单做决策。

1.2 YashanDB性能评估要覆盖哪几类场景？

实际做评估之前，我会先画一个场景清单，把所有要覆盖的业务模型列出来。YashanDB常见的使用场景大概可以分成三类：

• 传统OLTP在线交易：银行账务、计费系统、订单中心、会员服务。这类场景半夜可能有批处理任务，白天是高并发短事务，对TPS和响应时间双敏感。
• 混合负载：既有实时交易，又有联机统计分析，例如电商平台的订单查询连带销售报表统计。这类场景里读写比例不固定，一个慢查询可能把整个业务拖慢。
• 长稳型核心系统：要求数据库7x24小时不重启、不抖动，例如生产环境中的基础数据平台。这类场景最看重的不是峰值多高，而是持续跑三天、一周之后性能有没有衰减。

前面提到的6个重要指标不是随便凑出来的，它们分别对应这三类场景：事务吞吐量和并发连接能力对应业务高峰；响应时间和资源利用率对应混合负载体验；读写吞吐和稳定性对应长稳运行要求。把指标和场景绑定之后，测试才不是白忙活，最后得出的结论才真正能用来支持选型决策。

2. 6个关键指标逐个拆解

2.1 第一指标：事务吞吐量（TPS / TpmC）

事务吞吐量是评估OLTP数据库最直观的指标。TPS指每秒成功提交的事务数；TpmC则是TPC-C基准测试里每分钟处理的订单事务数，两者的区别主要在于业务模型不同。如果你要模拟的是一条包含下单、支付、发货的全链路交易，用TpmC或BenchmarkSQL这类工具更贴近真实；如果只是想看基础增删改查能力，sysbench的oltp模式就足够。

测试方法上，我一般按这几步走：

1. 建好业务模型对应的表结构，灌入足够历史数据。
2. 压测前先跑一段预热脚本，让数据尽量进入缓存。
3. 正式压测跑10到30分钟，记录压测时间内成功事务总数。
4. 用成功事务数除以压测时长，得到TPS。失败事务、超时事务、回滚事务都不算数。

有个点很容易被忽略：事务吞吐量要区分“数据库自己处理的事务量”和“客户端感知到的事务量”。两者之间隔着网络传输、客户端驱动封装、应用层逻辑，如果中间任何一环成为瓶颈，数据库再强也没用。我测YashanDB的时候会同时记录两个数字，一个来自压测工具的汇总，一个来自数据库侧的性能计数或系统表统计。两边差距明显偏大，说明问题大概率不在数据库本身，而在驱动或网络链路。

第二个容易踩的坑是冷热数据导致的数字失真。数据库都有缓存机制，YashanDB一样有内存缓冲池。数据没有进缓存时，每个查询都要走磁盘，吞吐量自然上不去。我第一次测一个国产库时没注意预热，跑出来的TPS比二次跑低了近50%，排查半天发现只是缓存没热。现在我固定先压20到30分钟，看TPS曲线稳定之后再记数，而不是一上来就取前几分钟的最大值。

2.2 第二指标：查询响应时间（RT与QPS）

响应时间直接决定用户体感。但这个指标要看的不只是平均值，我更关注P95甚至P99。平均值很容易被大量快查询拉低，掩盖掉一小撮慢查询的问题。举个例子：一次压测里平均响应时间是3毫秒，看起来不错，但P99是80毫秒。这就意味着有1%的查询要等近80毫秒，可能是索引没走对、锁等待、也可能是大事务阻塞了普通查询。平均响应时间达标但P99爆炸，在真实生产环境里表现为“系统总体不慢，但个别请求偶尔卡顿”。

测试响应时间时，我会同时看QPS，也就是每秒查询数。QPS和RT本质上是联动的：一个系统能支撑的QPS越高、RT越低，用户体验自然越好。但两者之间存在一个平衡点，超过某个负载后QPS继续增加，RT会急剧恶化。所以做压测时要记录负载、QPS、RT三者关系的变化曲线，而不是只看瞬间峰值。

实操层面，我把响应时间检查拆成三个动作：

• 压测工具侧：打开百分位统计，把P50、P95、P99、最大值全部记录下来，而不是只看平均值。
• 数据库侧：开启或查询慢SQL记录，把执行时间超过一定阈值的SQL捞出来，默认我常用100毫秒作为阈值。
• 执行计划核实：对慢SQL执行计划进行查看，确认是否命中预期索引、是否出现全表扫描、是否存在超大排序。

打个比方，看平均响应时间就像看城市道路平均车速，高峰期和半夜都没人管；看P99就像盯早晚高峰的堵点，这个数字才能暴露真正的交通问题。YashanDB上做这类排查，思路和Oracle系数据库有很多相通之处，关键是要把数据库侧给出的等待事件、锁等待、SQL统计和压测工具的数据对齐起来看。

2.3 第三指标：并发连接处理能力

并发连接能力是个很有迷惑性的指标，难点在于并发越高并不代表能力越强。当连接数超过某个临界点之后，数据库要同时调度大量线程，上下文切换开销会被放大，TPS不但不涨，反而会掉头向下。这个拐点才是我们真正要找的合理水位。

测试方法是用阶梯式并发压测：从50个并发连接起步，每组持续3到5分钟，依次涨到100、200、400、800，观察日志里TPS和响应时间的变化。一般来说，随着并发升高，TPS先快速上升，然后增速放缓，最后开始下降；响应时间则是先平稳、再抬升、并伴随抖动。TPS增速明显放缓且RT开始大幅上升的点，就是该环境下的合理并发上限。

YashanDB这边还要特别关注连接数参数配置。压测时碰到“连接数不够用”的报错，通常不是数据库不扛压，而是默认最大连接数设置偏小。生产环境一般不会直接开到上万个连接，因为大量连接本身会占用内存和调度资源，正确做法是配合连接池使用，把连接数控制在合理水位内。我见过一个团队把应用连接池最大值设置成5000，结果数据库没被打挂，应用层连接池先崩了，教训相当惨。

顺带说一句，判断并发是否过高的另外一个信号是数据库进程的CPU使用率。如果系统态占用很高、用户态很低，通常说明锁竞争或调度开销太大了。这种现象在并发测试里非常典型，看到TPS不涨、CPU却被打满，第一反应不是“再加压”，而是先掉头检查连接数和锁等待。

2.4 第四指标：读写吞吐量

读写吞吐量关注的是数据文件读写能跑多快，单位通常用MB/s或IOPS来衡量。事务吞吐量高不代表底层IO吞吐就高，比如纯查询场景可能TPS很高但磁盘几乎没压力；反过来，大量批量写入场景可能TPS不高，但磁盘已经打满，IO吞吐才是真正的瓶颈。

测试时会区分三种负载模型：纯读、写多读少、读写均衡。纯读场景关注的是缓存命中率够不够高、磁盘顺序读能不能顶住；写多读少场景关注的是日志写入和脏页刷盘能不能跟上事务提交速度；读写均衡场景则要看随机读写混合下的整体表现。

实际操作中我不会只依赖数据库压测工具，那样不好定位是数据库问题还是存储问题。我的做法是分两层测：

• 先用文件系统层面的工具，比如fio，直接把底层裸盘的随机读写和顺序读写能力打出来，得到硬件的上限。
• 再跑数据库级压测，通过系统IO监控观察磁盘的繁忙度和等待时长。

如果数据库层吞吐远低于文件系统层上限，说明瓶颈在数据库本身的写入机制、日志策略或锁竞争；如果两边都卡在同一个数字，那基本就是硬件极限了。做YashanDB评估时还要顺便看一下数据库把日志写到哪个设备、数据文件放哪个设备。日志盘和数据盘混用很容易造成写放大和IO抖动，生产环境的常规建议是分开部署，压测环境至少也要知道它们各自位于哪个磁盘上。

还有一个细节，大量小事务高并发提交时，每一次commit都可能触发磁盘写。如果数据库支持组提交或类似机制，把一小段时间内的事务攒成一批评处理，能显著减轻IO压力。遇到磁盘IO等待偏高的情况，可以在压测参数里调整提交策略，对比开启前后的吞吐变化。

2.5 第五指标：资源利用效率

资源利用效率是判断系统有没有被用好的关键，核心看四点：CPU使用率、内存使用率、磁盘IO和网络带宽。这个指标本身不追求任何一个资源达到100%，恰恰相反，某个资源接近极限往往暗示其他资源还有空闲，系统存在隐藏瓶颈。

举例说明。一次压测里TPS已经到顶，但CPU使用率只有40%，此时我们自然会怀疑瓶颈在别处。用工具看到磁盘util超过90%，可以判断IO是短板。或者CPU一半空闲，但大量时间花在系统态，并且观察到锁等待事件，就要检查并发配置和锁机制。YashanDB在这类排查里可以通过系统管理和诊断视图获取很多内部计数器，例如缓存命中率、锁等待次数、活跃会话数，把这些和操作系统层面的数据对齐，就能比较快地定位瓶颈。

内存利用效率最值得单独说。数据库通常会把热数据尽量放进缓冲池，命中率高则磁盘IO少，性能自然好。压测时如果不做预热，缓存命中率上不来，你测的其实是磁盘瓶颈，不是数据库的引擎能力。我建议在压测工具里预留一段预热时间，再通过数据库性能视图或系统表观察命中率数据，确保正式压测时命中率稳定在一个较高水平。

资源利用效率还要警惕“假瓶颈”。有一次我压测一个环境，CPU和IO都显示正常，但QPS一直上不去，最后排查发现是客户端压测机自身性能不足，单台客户端网卡已经跑满了。这种情况下数据库配置再好都无济于事。所以从CPU到网络，每个环节我都要看一眼，特别是跨机器压测时，千万不能忽略客户端所在的物理资源。

2.6 第六指标：稳定性与性能波动

性能好不好要看长期，稳定性比峰值更重要。一个数据库峰值TPS高固然好，但如果每5分钟就出现一次明显掉点，任何业务都扛不住。我用稳定性指标来评估长时间运行下的性能波动程度。

具体做法是连续压测3小时以上，甚至跑一晚上，每分钟记录一次TPS或响应时间样本。采集完数据之后计算变异系数，也就是标准差除以平均值。变异系数越大说明性能越不稳定，判断标准没有官方规定，但根据我自己的经验，控制在10%以内算不错，超过20%基本可以断定系统的某个环节存在问题。

导致性能波动的常见原因有很多：

• 定时任务：数据库内部的建索引、统计信息更新，或者业务系统的定时调度，都在某个时间点抢资源。
• 日志切换：数据库日志写满后切换到新文件那一刻，IO会出现短暂的峰值。
• 检查点机制：定时把内存中的脏数据批量刷到磁盘，期间会显著占用IO。
• 内存抖动：如果内存分配或大片缓存被清掉，响应时间会出现周期性上涨。
• 外部环境影响：备份脚本、监控采集、其他项目的任务在同一时刻运行，也会干扰压测数据。

我评估YashanDB稳定性时，会一边跑长压测，一边同时记录数据库的活跃会话数、等待事件和IO状态。当性能掉点出现时，翻一下同一时刻的数据库状态，基本都能找到根源。这种排查思路适用于任何数据库，思路比工具本身更重要。

3. 工具、环境与压测流程设计

3.1 压测工具怎么选

适合YashanDB的压测工具其实没有唯一答案，取决于测试目的和数据模型。我把常见的选择列成一个对照表：

我给了一条选型捷径：如果只是快速摸底，优先sysbench；如果要出标准报告用于选型，上BenchmarkSQL或HammerDB；如果是拿生产环境里的真实SQL做回归验证，就写一套针对业务的自定义压测脚本。YashanDB对哪一款工具支持得最好，建议以官方文档说明为准，但思路是完全一样的：工具只是手段，关键是业务模型和数据设计。

3.2 数据准备与参数计算

压测数据准备不足，结果分分钟失真。一个最简单的例子：如果数据库表里只有几百条数据，任何SQL都能走索引扫描，这根本测不出真实能力。通常至少要在表里灌入百万行以上的历史数据，让索引有一定的深度，让优化器有真正的选择空间。我常用的配置是8到16张表，每张表100万行起步，具体行数视磁盘空间而定。

并发数和目标QPS之间可以用一个简单的估算公式辅助设计：并发连接数约等于QPS乘以平均响应时间。例如业务目标是每秒处理5000次查询，平均响应时间设计为20毫秒，那么理论并发就在100左右。这个估算能防止一上来就把并发调到几千，白白给测试环境制造压力。压测时我会先按这个估算值设置一组并发，跑完看实际数据，再决定是否向上或向下一档调整。

3.3 可复用的压测流程

压测流程稳定，结果才可比较。我每次跑YashanDB性能测试前都会走过一遍这样固定流程，避免因为过程差异导致结果对不上：

1. 记录环境基线：CPU型号与核数、内存大小、磁盘类型与IO能力、数据库版本、关键参数值。
2. 初始化数据并预热：把数据灌入后，先跑一部分读混合操作，让缓存热起来。
3. 阶梯压测：从低并发开始，逐步增加并发，观察每个档位下的TPS、RT、资源数据。
4. 稳定压测：在合理并发档位下连续跑长时压测，记录性能波动情况。
5. 结果汇总：统一输出平均TPS、QPS、P95/P99延迟、资源利用率和稳定性指标。

这套流程看起来有点像“标准作业程序”，但它的价值就在于可复现。两次压测如果环境基线不一样，比如一次数据盘是NVMe，另一次是SATA，结果根本没有可比性。所有参数和步骤先记录在文档里，每次调整只改一个变量，数据才有参考价值。

4. 实操中的常见问题与排查实录

4.1 两次跑分结果相差50%，问题在哪？

我第一次测YashanDB时就被这个现象坑过。同样的脚本、同样的并发，第二次跑出来的TPS比第一次高了近一倍，最后发现是第一次压测时没有预热，数据大部分还在磁盘上。后来我习惯固定先压20到30分钟做预热，把预热的输出忽略掉，只统计预热完成后的稳定段。

另一个常见原因是环境不干净。压测开始前，要检查有没有别的进程在同时跑——比如备份任务、日志清理、监控采集，甚至上次压测遗留的客户端进程还占着连接和内存。我现在的习惯是压测前统一用命令查看进程、内存和磁盘IO状态，确认没有异常活动再开始。还有一个容易被忽略的点：压测机本身不要同时跑多路任务。如果一台压测机同时压两个数据库，结果两边都别想要。

4.2 TPS和CPU利用率双低，瓶颈到底在哪？

这种情况最迷惑人：TPS上不去，CPU也没满，感觉没有一个标准瓶颈。我的排查顺序是“先看等待，再看网络，最后看应用”。数据库侧可以查等待事件或类似计数器，看会话线程到底在等什么。如果大量时间等锁，那瓶颈在锁竞争或事务冲突；如果等网络IO，就要看客户端和数据库服务器之间的带宽及延迟；如果两条都正常，还要确认压测客户端是不是先到了瓶颈。

跨机房或者跨交换机压测时，网络带宽饱和是个高发问题。默认千兆网络的有效吞吐上限约100MB/s，如果数据吞吐需求超过这个值，QPS就上不去了。测试环境最好用万兆组网，或者至少确认网络不是瓶颈。

4.3 平均延迟很漂亮，P99却很糟糕，谁的锅？

这是典型的长尾延迟问题。压测结果的平均RT漂亮，但P99爆炸，很多时候是少数慢SQL或锁等待引起的。遇到这种情况我会把压测期间的慢SQL记录捞出来，看是不是有特定语句偶尔走错执行计划，或者某张大表触发了全表扫描。

还有一种可能是大量的行锁冲突。高并发下两个事务交叉更新同一批数据，等待链变长，特定请求就会卡很久。此时数据库侧锁等待计数会上升，可以通过统计信息确认。解决方向通常是调整事务逻辑、缩短事务时间，或者检查索引设计，让更新范围尽量减小。光靠调数据库参数很难根治业务模型层面的锁冲突。

我给排查过程整理了一张速查表：

4.4 参数改完好像没生效？

调整完配置参数后，一定要核实参数是否真正生效。有些参数需要重启实例或重新加载配置才有用，有些参数则存在上限保护。压测前我习惯把所有关键参数值记录下来，再用查询语句核对一遍实际运行值，而不是只检查配置文件。这个动作虽然基础，但防止了大量“改了但等于没改”的假象。

还有一个细节不要忽略：连接池的动态配置。应用侧连接池初始大小、最大大小设置不当，会对压测结果产生很大干扰。数据库的性能测试不只是数据库的事，应用层连接池、驱动参数、客户端机器性能都被包含在全链路里面。测试YashanDB时如果只想衡量数据库本身，就把相当于“客户端”这一层尽量做强一些，至少保证它不是首先被打满的环节。

5. 我的实际体会与复盘建议

5.1 做性能评估时我最怕的不是指标低，而是指标“假装正常”

压测做了几年，我发现真正难处理的不是数据库能力弱，而是数据自己会骗人。缓存没预热、客户端先到瓶颈、环境里跑着其他任务，哪一项都能把真实性能掩盖掉。每看到一个“正常得可疑”的指标，我第一反应是先质疑它的来源和条件，而不是急着写结论。评估YashanDB也一样，任何一个数字背后都要有一组完整的环境说明：硬件什么配置、数据多大、并发多少、跑了多久、有没有预热。没有这组上下文，TPS一万和TPS十万就没有任何比较意义。

5.2 团队如何把压测报告落到选型决策里

压测报告不能只是给管理层看一眼“性能达标”，而是要能回答业务最关心的几个问题：系统在预测峰值下还有多少余量，并发达到多少时会明显劣化，连续跑一周之后性能会不会下滑。我会在报告里固定放一张指标对比表，把6个指标分别列出实测值、业务需求和余量判断，用余量数值直接支撑选型判断。

最后分享一个很实际的小技巧：正式压测前，把每一项结果的判断场景写下来。比如“TPS达到3000并且P99低于50毫秒，同时并发200时无掉点，则该配置可支撑预估业务”。有了这个标尺，数据出来之后才不会陷入无休止的解读循环。数据库性能评估这件事，说白了就是用一套确定的方法，去测定一个不确定的系统。方法越稳定，结论才能越可信。