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模式就足够。测试方法上我一般按这几步走建好业务模型对应的表结构灌入足够历史数据。压测前先跑一段预热脚本让数据尽量进入缓存。正式压测跑10到30分钟记录压测时间内成功事务总数。用成功事务数除以压测时长得到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通用OLTP基础能力测试上手快、脚本简单、易改并发和表结构适合做横向对比BenchmarkSQLTPC-C标准化订单场景更贴近真实交易链能输出类TPC-C结果但搭建复杂HammerDB图形化压测出报告方便操作门槛低适合给管理层看的演示环境自编脚本业务SQL压测完全贴近实际最真实但前期开发成本和偶发问题需要处理我给了一条选型捷径如果只是快速摸底优先sysbench如果要出标准报告用于选型上BenchmarkSQL或HammerDB如果是拿生产环境里的真实SQL做回归验证就写一套针对业务的自定义压测脚本。YashanDB对哪一款工具支持得最好建议以官方文档说明为准但思路是完全一样的工具只是手段关键是业务模型和数据设计。3.2 数据准备与参数计算压测数据准备不足结果分分钟失真。一个最简单的例子如果数据库表里只有几百条数据任何SQL都能走索引扫描这根本测不出真实能力。通常至少要在表里灌入百万行以上的历史数据让索引有一定的深度让优化器有真正的选择空间。我常用的配置是8到16张表每张表100万行起步具体行数视磁盘空间而定。并发数和目标QPS之间可以用一个简单的估算公式辅助设计并发连接数约等于QPS乘以平均响应时间。例如业务目标是每秒处理5000次查询平均响应时间设计为20毫秒那么理论并发就在100左右。这个估算能防止一上来就把并发调到几千白白给测试环境制造压力。压测时我会先按这个估算值设置一组并发跑完看实际数据再决定是否向上或向下一档调整。3.3 可复用的压测流程压测流程稳定结果才可比较。我每次跑YashanDB性能测试前都会走过一遍这样固定流程避免因为过程差异导致结果对不上记录环境基线CPU型号与核数、内存大小、磁盘类型与IO能力、数据库版本、关键参数值。初始化数据并预热把数据灌入后先跑一部分读混合操作让缓存热起来。阶梯压测从低并发开始逐步增加并发观察每个档位下的TPS、RT、资源数据。稳定压测在合理并发档位下连续跑长时压测记录性能波动情况。结果汇总统一输出平均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记录捞出来看是不是有特定语句偶尔走错执行计划或者某张大表触发了全表扫描。还有一种可能是大量的行锁冲突。高并发下两个事务交叉更新同一批数据等待链变长特定请求就会卡很久。此时数据库侧锁等待计数会上升可以通过统计信息确认。解决方向通常是调整事务逻辑、缩短事务时间或者检查索引设计让更新范围尽量减小。光靠调数据库参数很难根治业务模型层面的锁冲突。我给排查过程整理了一张速查表现象优先排查方向平均RT正常但P99高慢SQL、锁等待、大事务阻塞TPS低且CPU空闲磁盘IO等待、网络带宽、客户端瓶颈TPS随并发升高反而下降上下文切换、连接数过高、锁竞争长时间压测周期性掉点定时任务、日志切换、检查点刷盘CPU打满但TPS不涨系统态占比高、内存命中率低4.4 参数改完好像没生效调整完配置参数后一定要核实参数是否真正生效。有些参数需要重启实例或重新加载配置才有用有些参数则存在上限保护。压测前我习惯把所有关键参数值记录下来再用查询语句核对一遍实际运行值而不是只检查配置文件。这个动作虽然基础但防止了大量“改了但等于没改”的假象。还有一个细节不要忽略连接池的动态配置。应用侧连接池初始大小、最大大小设置不当会对压测结果产生很大干扰。数据库的性能测试不只是数据库的事应用层连接池、驱动参数、客户端机器性能都被包含在全链路里面。测试YashanDB时如果只想衡量数据库本身就把相当于“客户端”这一层尽量做强一些至少保证它不是首先被打满的环节。5. 我的实际体会与复盘建议5.1 做性能评估时我最怕的不是指标低而是指标“假装正常”压测做了几年我发现真正难处理的不是数据库能力弱而是数据自己会骗人。缓存没预热、客户端先到瓶颈、环境里跑着其他任务哪一项都能把真实性能掩盖掉。每看到一个“正常得可疑”的指标我第一反应是先质疑它的来源和条件而不是急着写结论。评估YashanDB也一样任何一个数字背后都要有一组完整的环境说明硬件什么配置、数据多大、并发多少、跑了多久、有没有预热。没有这组上下文TPS一万和TPS十万就没有任何比较意义。5.2 团队如何把压测报告落到选型决策里压测报告不能只是给管理层看一眼“性能达标”而是要能回答业务最关心的几个问题系统在预测峰值下还有多少余量并发达到多少时会明显劣化连续跑一周之后性能会不会下滑。我会在报告里固定放一张指标对比表把6个指标分别列出实测值、业务需求和余量判断用余量数值直接支撑选型判断。最后分享一个很实际的小技巧正式压测前把每一项结果的判断场景写下来。比如“TPS达到3000并且P99低于50毫秒同时并发200时无掉点则该配置可支撑预估业务”。有了这个标尺数据出来之后才不会陷入无休止的解读循环。数据库性能评估这件事说白了就是用一套确定的方法去测定一个不确定的系统。方法越稳定结论才能越可信。