做数据库选型或者接手一套新数据库的维护时我最常被问到的问题是YashanDB到底行不行而行不行这个判断落到技术层面其实就是一套可量化的性能指标在说话。去年底我完整地做了一轮YashanDB的性能评估从环境搭建到压测工具选型再到六个核心指标的逐项拆解踩了坑也沉淀了不少经验。这篇就把我这轮评估的完整思路和方法摆出来不讲虚的全是怎么测、怎么读数、怎么判断的实操内容。1. 把YashanDB摆上测试台之前我先准备了这几件事性能评估最怕的结果不是性能差而是数据不可信。一套做出来连自己都说服不了的数据拿到评审会上就是废纸。所以在正式压测之前我把环境、工具、数据规模这三件事全部钉死确保后面跑出来的每一组数据都有可比性和可复现性。1.1 被测环境怎么搭才能得出可信数据先说硬件。数据库压测对存储介质的敏感度非常高我这次评估用的是NVMe SSD建议不要用SATA盘或者网络存储否则IO延迟会把CPU层面的性能差异彻底掩盖掉。资源配置上我给的是一台16核32线程、64GB内存的物理机操作系统是CentOS 7.9文件系统直接用的XFS。机器上除了操作系统和监控Agent之外不跑任何业务避免其他进程抢占CPU和内存。接着是YashanDB本身的部署模式选择。YashanDB有单机、共享集群、分布式三种产品形态我的建议是第一轮评估一定先跑单机。原因很简单——单机模式下CPU、内存、IO的调用路径最短所有的性能瓶颈都直接暴露在最底层。如果单机的基线数据都拿不到直接上集群或者分布式遇到性能问题你根本分不清是数据库引擎的问题还是网络同步、分布式协调带来的损耗。内存参数是测试前必须调的。数据库的buffer pool缓冲池大小直接决定了缓存命中率而缓存命中率又直接影响IO压力。我在YashanDB的配置中把数据缓冲区调到了物理内存的50%左右日志缓冲区保持默认然后重启实例让配置生效。这里有个容易忽略的点改完内存参数后一定要查看系统日志确认配置加载成功不要想当然觉得改了就生效。提示压测前先跑一条SELECT 1 FROM DUAL确认连接正常再用系统自带的状态视图查一下实例的启动时间和内存分配情况。先确认数据库是健康状态再开始谈压测。1.2 压测工具怎么选不要一上来就TPC-C很多人一说数据库压测就提TPC-C但TPC-C的完整审计流程对环境和脚本的要求极高适合厂商做官方背书不适合工程师做日常评估。我的做法是分层测试先用sysbench这类通用工具做基础的OLTP读写测试拿到第一轮数据再用BenchmarkSQL或者自建脚本做贴近业务的复杂事务模拟。为什么这么做因为sysbench的优点是标准化程度高、参数可控、结果可复现适合做横向对比而BenchmarkSQL的事务模型更接近真实的订单、支付、库存场景适合验证YashanDB在复杂SQL和事务并发下的表现。两轮数据结合起来既能看到引擎的理论极限也能看到业务贴近度。工具确定后压测参数也要提前固定。比如并发线程数、单条事务的SQL复杂度、测试时长、预热时间这些必须写进测试方案里。我专门建了一个压测参数清单每次跑完都把当时的参数贴在结果旁边省得后面分析数据时还要回忆当时用的是多少并发。1.3 数据规模和冷热分离的讲究压测数据量不是越大越好而是要和内存大小形成合理比例。我的原则是基础数据量是内存缓冲区的2到4倍。比如64GB内存、分配了32GB给buffer pool那基础数据就准备80GB到128GB。这样保证一部分数据常驻内存一部分数据需要从磁盘读取才能真实反映数据库混合读写的表现。测试表的字段设计也别偷懒。我建了用户表、订单表、商品表三张核心表用户表500万行订单表3000万行商品表50万行。索引尽量贴近真实业务的组合索引和普通索引混合。数据一次性灌完后先跑一轮全表扫描的查询作为预热让热门数据页真正进到缓存里。预热不充分的后果很直接前面的数据会偏低而且波动大整个结果没法用。2. 第一对指标吞吐量和响应时间必须放在一起读这大概是性能评估里最核心的一对指标了。但实际工作时我看到太多人只盯着TPS一个数忽略了响应时间的分位数最后对系统性能的判断严重失真。2.1 TPS和QPS数据库每秒到底干了多少活先分清两个概念TPS是每秒完成的事务数一个事务可以包含多条SQL语句QPS是每秒处理的查询请求数通常按单条SQL来算。对OLTP业务来说TPSC是更重要的指标因为它衡量的是完整业务动作的完成能力QPS更适合评估读写分离架构下只读节点的查询能力。我在YashanDB的评估中对sysbench的OLTP读写测试取TPS对只读测试取QPS。实测下来在16核环境下单机YashanDB的TPS表现处于主流数据库的正常区间具体数值受数据规模和并发数影响很大不建议直接拿网上的跑分做对比。跑分对比必须满足两个前提一是测试环境硬件一致二是数据规模、参数配置一致。缺一个对比就是耍流氓。2.2 响应时间用户感受到的快和慢响应时间上我常看四个数平均值、p50、p99、p999。平均值最容易骗人——一个系统如果99%的请求都在10毫秒内完成但1%的请求因为锁等待或者IO抖动跑到2秒平均值可能只有30毫秒表面看完全正常实际上用户体验已经很糟糕了。p99的意义在于排除掉那1%的极端异常后绝大多数请求的响应上界在哪里。p999则是拔高到千分之一的极端场景适合对延迟极敏感的金融类交易。压测YashanDB的OLTP场景时我习惯同时记录这四个数。如果p50低但p99突然高出一两个数量级大概率是测试过程中出现了锁竞争、日志切换或者缓存未命中的抖动这些信号后面逐条排查。2.3 高吞吐和低延迟不能兼得时怎么权衡这里有个业务上的取舍问题。在评估阶段我会把两个指标分开看先测出规定的并发下能做到的最大吞吐再测出在严格延迟约束下的吞吐上限。比如设定p99必须在50毫秒以内的约束看这个约束下TPS能到多少再把约束放宽松到200毫秒看TPS能提升多少。这个差值就是延迟指标对应的性能成本。实际上数据库本身的调优也能影响这对指标的平衡。缓冲池大小、日志刷新频率、是否开启自动提交、索引设计是否合理都会同时影响两个指标。测试过程中我调整过几次YashanDB的日志提交策略发现对延迟的影响非常明显。这类调整要不要做完全看业务场景——如果业务允许一点数据丢失窗口可以换更高的吞吐如果业务要求强一致就必须牺牲部分吞吐。压测就是要通过这种调节把系统的能力边界摸清楚。3. 第二对指标并发能力和资源消耗一个看上限一个看代价吞吐和延迟是数据库的外部表现但光看外部表现不够我接着挖了两层系统承受并发时的实际能力上限以及为这个上限付出的资源代价。3.1 并发爬坡测试线程数不是越多越好并发能力的测试方法我习惯用爬坡法从1个并发线程开始依次加到4、8、16、32、64、128、256每个档位固定跑5分钟记录该档位下的TPS和响应时间最后把数据画成曲线。这条曲线的形状能说明很多问题。理想情况下TPS应该随并发数线性增长然后增速放缓到某个点达到峰值之后继续加并发TPS持平甚至下降。如果128线程和256线程的结果几乎一样说明系统已经到瓶颈加线程只是增加无谓的上下文切换。如果并发一旦超过32就剧烈下降那大概率是锁竞争或者连接池配置不当。我在YashanDB上观察到的情况是并发在64以内时吞吐量增长接近线性从128开始增速放缓但曲线仍然稳定没有出现明显的断崖式下跌。这说明它的锁机制在多线程扩展上做得比较稳健。不过要注意的是这轮的测试数据是在单机16核环境下拿到的换到更大规格的机器或者集群环境曲线形状一定会变所以并发测试一定要在目标生产规格的环境上重复不能拿低配环境的结论去推断高配。3.2 资源账怎么算CPU、内存、IO三项消耗逐一盘跑完并发测试我会同时盯着三张报表看CPU利用率、内存使用、磁盘IO。CPU是最直观的。压测时我先看整体CPU使用率再看核心是否均匀。合理的状态是所有核心占用率大致接近如果出现个别核打满、其他核空闲那是典型的单线程瓶颈比如某个热点字段的锁串行化。YashanDB在并发场景下的CPU均衡性不错但这不是天生保证的——如果某条SQL写得很烂、走了全表扫描照样能把单核拉满。内存看的是两件事进程常驻内存是否稳定增长以及缓冲池命中率。缓存命中率我会用数据库状态视图直接查正常情况下OLTP混合读写命中率应该在95%以上。如果命中率跌到90%以下说明缓冲池配小了或者数据访问模式极度分散这时优先调内存而不是怀疑SQL。磁盘IO的关注点不是带宽而是延迟和队列深度。用iostat观察await和util两个值await表示IO响应延迟正常应该在几毫秒到十几毫秒util超过90%说明磁盘接近饱和。我在压测中故意把数据量做得超过内存目的就是让一部分随机读真实落盘从而观察磁盘在随机IO下的真实表现。提示压测过程中每5秒采样一次资源数据防止只看到结束时的瞬间状态。有些性能问题是在测试中段出现的结束后去看top已经看不到任何痕迹了。3.3 资源的代价最终要换算成成本资源消耗指标的终极意义是算成本。一台16核的机器跑出3万TPS和一台8核的机器跑出2.8万TPS虽然大机器看起来性能更好但如果业务只需要2万TPS那8核机器一台就够省下的硬件成本是实打实的。我在评估报告里会把资源消耗归类成两类可压缩成本和不可压缩成本。CPU和内存是可通过SQL优化、参数调优来压缩的磁盘IO的延迟瓶颈最难压缩一旦随机IO成为瓶颈通常只能靠加缓存或者换更快的存储介质来解决。这样分类的好处是给业务方提建议时可以直接说要提升性能优先优化哪些SQL、调哪些参数而不是一句建议加机器了事。4. 第三对指标稳定性和扩展性短跑和长跑的差距如果说前两对指标是短跑成绩那稳定性和扩展性就是长跑耐力。数据库选型最怕的就是短跑满分、长跑不及格——峰值性能好看跑上半小时就开始掉链子这种系统上线就是灾难。4.1 稳定性测试一小时起步重点盯波动曲线我跑稳定性测试的习惯是至少连续压测1小时。短于这个时间很多慢性问题根本来不及暴露。测试期间持续记录TPS、响应时间、错误率三个数据重点看它们的波动情况。一个稳定的系统TPS曲线应该是围绕均值小范围波动的。如果曲线出现周期性的凹陷找一下凹陷的时间点是不是对应全量备份、日志切换或者统计信息自动收集——这些后台任务经常成为性能杀手。YashanDB在这轮长时间测试中有一个值得说的表现长时间压测下的TPS波动范围控制在很小的区间内没有出现明显的性能衰减或内存持续攀升。内存持续攀升是我特别警惕的信号那通常意味着某个对象没有被及时释放长时间跑下去就是OOM。稳定性测试的另一个观察点是慢SQL的增长。压测开始阶段如果出现几条慢SQL可能是冷数据首次访问导致的缓存未命中但如果慢SQL数量随着时间推移持续增加那可能是缓存失效策略或者数据分布变化导致的需要把测试期间产生的慢日志导出来逐个分析。4.2 扩展性测试加资源之后性能涨多少扩展性测试解决的是预判问题未来业务增长这套数据库能不能扛得住。扩展性主要看两条线纵向扩展是加CPU和内存横向扩展是加节点。纵向扩展的测试方法很简单同一套压测方案分别跑在8核、16核、32核的机器上看吞吐量是否等比例上升。但这个测试成本太高我一般不做完整版只跑16核和32核两组做推算。横向扩展则针对YashanDB的集群或分布式形态从单机扩到三节点再扩到五节点看整体吞吐量是否接近线性增长。需要清醒认识的是没有任何数据库能做到完美的线性扩展。集群节点之间的数据同步、分布式事务协调、网络开销都会吃掉一部分性能。评估扩展性时我会算一个扩展效率扩展后吞吐量增量除以扩展的节点数。如果每加一个节点的增量不到单节点性能的70%那就要考虑架构上是否有问题还是业务的数据模型根本不适合分布式。4.3 稳定性和扩展性对选型决策的影响最大这四个小时的测试跑完之后我对YashanDB的总体印象是这样的单机模式下的性能表现中规中矩但胜在稳定扩展性方面共享集群和分布式架构的功能差异很明显选型时不能只考虑性能指标还要看业务系统的数据规模是否真的需要走分布式路线。如果业务数据量和并发量没有大到单机扛不住的程度强行上分布式架构反而会引入不必要的复杂度性能还可能不如深度调优后的单机。5. 六个指标怎么合成最终结论我的判断框架和几个容易忽略的坑数据都拿到手之后最后一步是把六个指标拼成一张完整的图。这也是评估工作里最容易被轻视的一环——很多人跑完数据就直接写性能达标或者性能不达标完全不管这些指标之间的内在关系。5.1 指标的优先级不是固定的取决于业务场景六指标本身的权重因业务而异。OLTP在线交易系统吞吐量和稳定性是首要的p99延迟也必须有硬约束OLAP分析类业务处理速度比并发能力更关键资源消耗的关注点也要从CPU转向IO带宽混合负载场景则要在两对指标之间找平衡。我习惯把评估结论分成三种推荐、有条件推荐、不推荐。推荐意味着六项指标里关键项全部满足业务预期有条件推荐意味着存在短板但可以通过配置调整、SQL优化或者架构变通来弥补不推荐则意味着硬伤无法绕开。YashanDB在这轮评估中如果面向典型的OLTP业务场景结论是有条件推荐——基础性能在线但部分高级特性在不同产品形态下的表现差异较大需要结合具体场景二次验证。5.2 实测中常见的几个坑每一个都是我踩过的第一个坑是预热不充分。数据加载完就开跑结果前面半小时都在做缓存填充读出来的数据忽高忽低。解决方法是正式压测前先跑一轮只读查询来预热缓存直到连续两次查询耗时接近再开始正式测试。第二个坑是线程数拉得太高。很多人觉得并发线程越多越能测出性能上限实际上一旦超过硬件的物理线程数操作系统就开始做上下文切换吞吐反而下降。判断方法很简单观察吞吐随并发增长停滞甚至下降的拐点那个拐点才是系统真实能力的边界。第三个坑是只盯着峰值不看曲线。峰值只能说明系统在某一个瞬间的极限完全不能代表持续服务能力。真正判断性能要看整条曲线的走势、波动幅度和异常点分布。我前面说的一小时压测就是为了补这个信息。第四个坑是忽略连接池的影响。压测工具直接直连数据库和通过连接池访问数据库结果差距很大。如果业务实际是通过连接池访问的那压测也必须走连接池否则测出来的结果没有参考价值。5.3 选型评估的最终建议永远要用自己的数据说话做完这轮评估后我自己最大的体会有两点。第一任何数据库的公开性能和网上跑分都只能当作参考坐标。同一款数据库在不同硬件、不同负载模型、不同参数配置下的表现天差地别。只有用自己的业务数据、自己的SQL、自己的压测场景跑出来的成绩才算数。第二性能评估不是一次性的工作。数据库上线后随着数据量增长、业务模式变化性能会持续漂移。我的做法是沉淀一套完整的压测脚本和参数基线每季度做一轮基准回归一旦发现关键指标偏离基线超过15%就主动排查原因。这套流程的价值比单次评估大得多。最后再分享一个实操细节写性能评估报告时我会把每次压测的完整参数、环境信息和原始数据全部存档包括测试时间、工具版本、配置参数、数据量、每档并发的完整结果。这些看似琐碎的记录在做前后对比和问题回溯时是救命的东西。评估的真正价值从来不在结论本身而在这套数据能不能支撑后续每一次决策和每一次疑问的解答。