企业官网建设流程全解析

数据库选型这件事，最怕的就是拿一张跑分表当决策依据。我用 HammerDB 做过不少轮横向对比，六个主流关系型数据库放在同一套硬件上跑 TPC-C，结论经常和厂商宣传、社区口碑对不上：有的库单看峰值很漂亮，稳态却掉得厉害；有的库 NOPM 不高，但延迟曲线平得像一条直线，放到真实业务里反而更省心。HammerDB 支持六大数据库的对比测试，难点从来不是把测试跑起来，而是测试结果如何解读——同一份数字，会读的人能看出瓶颈在哪一层，不会读的人只能得出"甲比乙快 30%"这种经不起追问的结论。这篇就把我踩过的坑、用的对齐清单、以及读数的四层框架摊开讲，适合已经能跑通 HammerDB、但对着结果窗口发愁的同行，也适合刚接手选型评估、需要一套可复现方法的人。

1. 先对齐计量口径：HammerDB 的 NOPM 到底代表什么

很多人第一次看 HammerDB 的结果窗口，注意力全在最后那个 NOPM 数字上，然后直接截图发群里。这个习惯很危险，因为 HammerDB 给出的不是一个"性能分数"，而是一组带时间维度的过程数据。你不清楚它是怎么算出来的，就没法判断这个数字能不能用。

1.1 TPC-C 业务模型与被放大的写路径

HammerDB 的 OLTP 负载复刻的是 TPC-C 的业务模型：一个分销商的订单管理系统，包含新建订单、支付、订单查询、发货、库存查询五类事务。这五类事务在标准里的比例大约是 45%、43%、4%、4%、4%，也就是说新建订单和支付这两类写操作占了将近九成。这个比例非常关键，它意味着 HammerDB 的 TPC-C 本质上是一个写密集型负载，而不是很多人想象中的"混合读写"。

为什么这一点影响读数？因为写密集型负载对存储的同步写延迟极其敏感，对日志子系统的压力远大于对数据缓冲区的要求。我在早期做过一次对比，两台配置几乎相同的机器，唯一差别是一台把日志盘放在机械盘上，另一台放在固态盘上，跑出来的 NOPM 差了将近四倍。如果当时不看业务模型，只比数字，很容易得出"某个数据库写性能差"的错误结论，实际上是盘的问题。

所以读结果的第一步，是先把被测负载的画像搞清楚：写占比多少、事务粒度多大、热点在哪张表。TPC-C 里最热的表是新订单表和库存表，库存表还会因为仓库编号的分布产生热点行竞争，这个特性在后面解读锁等待指标时会反复用到。

1.2 NOPM 与 TPM 的换算关系及误用

HammerDB 结果窗口里通常同时出现 NOPM 和 TPM 两个值。NOPM 是每分钟新建订单数，TPM 是每分钟总事务数。按前面说的 45% 比例，理论上 TPM 大约是 NOPM 的 2.2 倍。这个换算关系看起来简单，但误用率极高。

我见过最常见的错误，是拿 A 库的 NOPM 去比 B 库的 TPM，然后说"A 库比 B 库慢一半"。这两个指标根本不是同一个量纲。还有人拿 NOPM 直接乘以 60 再乘以 8，估算"日处理订单量"，完全忽略了真实业务的事务构成和并发特征，这种推算除了好看没有任何意义。

真正该做的是把两个指标放在一起看比值。如果某个库的 TPM 与 NOPM 之比明显偏离 2.2，说明事务构成出了问题，可能是某类事务因为锁冲突被大量回滚重试，也可能是测试脚本在某个环节卡住了。这个比值本身就是一个健康度信号，比绝对值更能说明问题。我在一次测试里发现某库的比值只有 1.6，追下去才发现是发货事务因为批量提交策略导致大量等待，调整提交批次后比值回到 2.1，NOPM 也跟着涨了一截。

1.3 为什么同一个库两次跑分能差一倍

同一套环境、同一个库、同样的参数，跑两次结果差一倍，这事我遇到过不止一次。原因通常不在数据库，而在测试过程本身。

第一是预热。HammerDB 启动后会先跑一段时间的 rampup，这段时间内缓冲池还在填充、执行计划还在生成、连接还在建立，吞吐是爬坡状态。如果你的统计窗口把 rampup 也算进去了，平均值会被严重拉低。正确做法是等曲线进入平台期之后再开始计时，或者干脆把 rampup 时间设得足够长，让统计窗口完全落在稳态区间。

第二是检查点。HammerDB 有一个检查点间隔参数，默认会周期性触发数据库的检查点动作。检查点期间会有大量脏页刷盘，吞吐会出现规律性的凹陷。如果测试时长刚好是检查点间隔的整数倍，凹陷被平均掉；如果不是，某一次测试可能恰好踩在凹陷里，数字就难看了。我一般会把测试时长设成检查点间隔的整数倍，并且在结果曲线上确认没有明显的周期性抖动。

第三是后台任务。PostgreSQL 的自动清理、MySQL 的刷脏线程、SQL Server 的惰性写入器，这些后台任务在测试期间的行为会直接干扰吞吐。不把这些任务的状态控制住，两次测试的差异可能比两个数据库之间的差异还大。

2. 六套库拉到同一条起跑线：环境对齐清单

横向对比最容易翻车的地方，不是测试本身，而是六套环境根本没对齐。硬件差一档、文件系统不一样、内核参数没调、数据装载方式不同，任何一项都会让结论失真。我现在的习惯是先列一张对齐清单，六套环境逐项打勾，全部通过才开始跑。

2.1 硬件、操作系统与应用层的统一

硬件层面要求同型号、同数量、同插槽位置的内存条和硬盘，这一点听起来是废话，但真有人拿两台不同代的机器做对比。更隐蔽的是存储配置：六套库如果有的用独立日志盘、有的日志和数据混放，写路径的差异会直接体现在结果里。我的做法是统一分成数据盘、日志盘、临时盘三块，六套库按同样的方式挂载，文件系统统一，挂载参数统一。

操作系统层面要统一内核版本和关键参数。文件句柄上限、内存过量提交策略、透明大页开关、IO 调度器，这四项必须一致。透明大页尤其容易被忽略，它对某些数据库的延迟影响能达到两位数百分比。我一般会关掉透明大页，把 IO 调度器统一设成适合固态盘的模式，然后把六套环境的参数快照存档，出了问题可以回溯。

应用层指的是 HammerDB 客户端本身。客户端不要和数据库抢同一台机器的资源，最好独立部署。客户端到数据库的网络链路要一致，延迟差异控制在毫秒级以内。如果六套库分布在不同网段，先测一遍网络往返时间，差异超过阈值就换机器，否则你测的是网络不是数据库。

2.2 warehouse 数量与虚拟用户的配比换算

HammerDB 的 TPC-C 用仓库数量来定义数据规模，一个仓库大致对应十万件商品、十万条库存、三万客户、三十万订单行，数据量在百兆级别。虚拟用户数则代表并发终端数。这两个参数不是随便填的，它们之间有一个经验配比：每十个仓库对应一个虚拟用户比较接近真实业务的争用强度。仓库太少、用户太多，热点行竞争会被极度放大，测出来的是锁性能不是综合性能；仓库太多、用户太少，数据分布太散，缓存命中率虚高，测出来的数字好看但不真实。

我一般会按目标数据量先定仓库数，再按一比十左右定虚拟用户数，然后做一轮小规模预跑，看锁等待占比是否在合理区间。如果锁等待占总等待时间的比例超过三成，说明争用过强，要么加仓库要么减用户。这个预跑步骤很多人跳过，直接上正式测试，结果曲线一塌糊涂，回头重跑浪费的时间更多。

还有一个参数叫"使用全部仓库"，打开后虚拟用户会均匀分布到所有仓库上。这个选项在仓库数远大于用户数时意义不大，但在仓库数接近用户数时影响很大，务必在六套环境里保持一致，否则分布策略不同，热点分布就不同。

2.3 数据装载方式对后续测试的隐性影响

建库阶段的数据装载方式，会通过索引碎片、统计信息、页填充度这几个途径影响后续的测试结果，而且影响会持续整个测试周期。

Oracle 用直接路径装载、SQL Server 用批量复制、PostgreSQL 用 COPY、MySQL 用批量导入、Db2 用装载工具，这些工具的默认行为各不相同。有的会重建索引，有的不会；有的会更新统计信息，有的需要手动触发；有的按顺序填充页，有的随机填充。如果不做统一处理，六套库的物理数据布局差异可能很大。

我的做法是装载完成后统一做三件事：重建或整理所有索引、更新全库统计信息、检查页填充度是否在合理区间。这三步做完再开始测试，能消除大部分装载差异。另外装载完成后的第一次全表扫描会触发大量物理读，所以正式测试前要跑一轮预热，把热数据读进缓冲池，否则第一分钟的曲线会非常难看。

3. 六个数据库的建库与驱动差异：逐个拆

HammerDB 对六个库的支持程度不一样，有的开箱即用，有的要折腾半天。这一节把每个库在建库和驱动层面的关键差异拆开讲，这些都是影响结果可比性的实质因素，不是配置洁癖。

3.1 MySQL 与 MariaDB 的装载与参数

这两个库的建库流程最接近，都用批量导入工具装载数据，但有几个坑必须提前处理。

第一个是本地文件导入开关。批量导入依赖客户端读取本地文件的能力，这个能力默认是关闭的，不开会在装载阶段直接报错。同时还要检查文件导入目录的限制参数，如果设成了空值表示禁止任意目录，设成特定路径则只允许该路径。我一般会在测试环境里临时放开，装载完成后立刻收回。

第二个是缓冲池大小。MySQL 和 MariaDB 的缓冲池是影响 OLTP 性能的第一参数，建议设成物理内存的五到七成。设得太小，测试期间会持续出现物理读，NOPM 上不去；设得太大，可能触发内存交换，延迟曲线会出现尖刺。这个参数在六套库里必须按同样的比例设置，不能有的给七成有的给三成。

第三个是日志刷盘策略。为了追求吞吐，很多人会把刷盘策略调成每秒刷一次甚至交给操作系统决定，这样测出来的数字会明显偏高，但牺牲了持久性。如果六套库里只有这一套这么调，对比就失去意义了。我的原则是六套库统一采用兼顾持久性的配置，谁也别开小灶。

MariaDB 在这几个参数上和 MySQL 基本一致，但它的刷脏线程行为和版本差异较大，建议固定版本号，不要跨小版本对比。

3.2 PostgreSQL 的自动清理与 WAL

PostgreSQL 最大的干扰源是自动清理。TPC-C 是写密集型负载，会产生大量死元组，自动清理进程会在测试期间频繁启动，占用大量 IO 和 CPU。如果不做处理，你测出来的是"数据库加自动清理"的综合性能，而不是数据库本身的处理能力。

我的处理方式是在测试期间调整自动清理的触发阈值，让它不要在高负载时段频繁启动，同时把清理的休眠时间调短，避免积压。测试结束后再恢复默认值。这里要注意，完全关闭自动清理也不可取，死元组堆积会导致表膨胀，后期查询性能断崖式下跌，测试后段的数字会失真。

写入日志是另一个关键点。PostgreSQL 的日志刷盘由提交时的同步设置控制，同步提交能保证持久性但增加延迟，异步提交反过来。六套库必须统一策略。另外日志的检查点间隔和单次刷脏量要调大，否则检查点期间会出现明显的吞吐凹陷，前面讲过的周期性问题就是这么来的。

共享缓冲区的设置逻辑和 MySQL 类似，但 PostgreSQL 还依赖操作系统的页缓存，所以共享缓冲区不宜设得过大，一般三到四成物理内存比较稳妥，剩下的留给系统缓存。

3.3 SQL Server、Db2、Oracle 的日志与内存

这三个商业库的架构差异更大，配置项也更细，但影响可比性的核心点其实就那么几个。

SQL Server 的关键在于内存上限和批量装载方式。内存上限不设，它会逐渐吃掉整机内存，导致操作系统层面开始换页，延迟飙升。批量装载要确认批量工具已启用，装载批次大小要统一。另外它的检查点行为受恢复间隔参数控制，这个参数直接影响检查点频率，六套环境里要按相近的频率设置。

Db2 的关键在于锁列表大小和日志空间。TPC-C 的并发更新很容易把锁列表撑爆，一旦溢出就会走锁升级，大量行锁变成表锁，吞吐瞬间塌掉。日志空间同理，日志满了会强制归档，归档期间写入阻塞。这两个参数我一般会给得比较宽裕，然后观察锁等待和日志等待指标来确认是否还有压力。

Oracle 的关键在于重做日志组的数量和大小。重做日志切换过于频繁会出现检查点未完成的等待，表现为吞吐的规律性抖动。我一般会给三组以上的重做日志，单组大小按测试时长的写入量估算。另外它的系统全局区内存分配要合理，程序全局区要给足，否则连接数一多就开始报内存不足。

下面这张表是我常用的关键参数对齐清单，六套环境按这张表逐项填，填不齐就别开始跑。

3.4 驱动与客户端版本的一致性

这一条最容易被忽略。HammerDB 连接不同数据库用的是不同的客户端库，这些库的版本差异会带来额外的开销差异。比如某个库的客户端驱动新版本在批处理上有优化，旧版本没有，同样的数据库配置测出来能差一成以上。

我的做法是固定所有客户端驱动的版本，六个库各自选一个经过验证的稳定版本，记录在测试报告里。测试期间不升级任何驱动，也不混用不同来源的驱动包。另外客户端的连接池配置要一致，连接数上限、超时时间、重试次数，这些参数不一致同样会污染结果。

4. 跑出来的数字按层次读：吞吐、延迟、资源、一致性

拿到结果之后怎么读，这是整篇文章的核心。我的习惯是把结果拆成四个层次，从外到内依次看，任何一层出现异常，就停下来先解决这一层，不要急着往下比。

4.1 吞吐看稳态平台而非峰值

结果窗口里显示的 NOPM 是一个平均值，这个平均值包含爬坡期和稳态期。真正有意义的数字是稳态平台的高度，而不是平均值，更不是曲线上的最高点。

我一般会导出曲线数据，把爬坡段切掉，只统计平台段的均值、标准差和最小值。均值代表能力，标准差代表稳定性，最小值代表最差情况。三个数放在一起看，才能判断这个库是"稳定输出"还是"忽高忽低"。

举个我自己的经验：有两个库的平均 NOPM 几乎一样，但一个标准差很小，另一个波动超过两成。放到生产环境里，波动大的那个意味着高峰期可能掉到谷底，业务侧的体验会非常差。只看平均值根本发现不了这个差异。

另外要注意平台的持续时间。有些库在测试的前半段表现很好，后半段因为死元组堆积、日志空间紧张、缓存命中率下降而掉下来，平均值被前半段拉高，看起来还不错。这种情况必须看整条曲线的趋势，确认平台段没有向下倾斜。

4.2 延迟必须和并发一起看

单独看吞吐是片面的，必须把延迟和并发放在一起。我一般会看三个数：平均响应时间、百分之九十五分位响应时间、以及最大响应时间。

平均响应时间容易被少数极快的事务拉低，掩盖长尾问题。百分之九十五分位更能反映大多数用户的真实体验。最大响应时间则用来发现偶发的长阻塞。三个数里，分位值最重要。

如果吞吐上不去，同时分位延迟很高，说明系统在排队，瓶颈在资源侧。如果吞吐上不去，但分位延迟很平稳，说明并发压力根本没给到位，可能是虚拟用户数太少，或者某个环节成了串行瓶颈。

还有一种情况是吞吐和延迟都正常，但最大响应时间出现周期性尖刺。这通常是检查点、日志切换、后台任务引起的，需要结合时间点去对后台任务的执行记录。我遇到过一次，尖刺每五分钟出现一次，追下去发现是某个库的统计信息自动更新任务在整点触发，最后调整了触发窗口才解决。

4.3 资源侧证据链怎么建立

光看数据库指标还不够，必须建立从数据库指标到操作系统资源的证据链，否则你只知道"慢"，不知道"为什么慢"。

我的做法是测试期间同步采集四组数据：数据库侧的等待事件、操作系统侧的 CPU 使用率与 IO 延迟、存储侧的每秒读写次数与队列深度、网络侧的往返时间。四组数据按时间轴对齐，任何一项指标异常都能快速定位到对应的时间点，再看那个时间点上其他三项在干什么。

常见的对应关系是这样的：CPU 使用率饱和、等待事件以 CPU 相关为主，说明是计算瓶颈；IO 延迟升高、队列深度积压、等待事件以写日志相关为主，说明是存储瓶颈；锁等待占比高、CPU 和 IO 都不高，说明是业务逻辑层面的争用；网络往返时间抖动，说明是链路问题。

这套对应关系不是绝对的，但能覆盖八成以上的情况。关键是四组数据要同时采集、同时对齐，只采一组等于没采。

4.4 一致性校验是结果可信的前提

HammerDB 的 TPC-C 负载在标准里是有一套一致性校验的，用来确认跑出来的事务确实是按业务规则执行的，没有因为并发冲突产生脏数据。这个校验不做，你的数字再漂亮也可能是作弊换来的。

比如某个库为了追求吞吐，把隔离级别调低了，读到脏数据也能提交，事务成功率虚高，NOPM 自然好看。这种情况下测出来的数字和真实业务场景完全脱节。

我在每轮测试结束后都会做一次一致性校验，把校验不通过的结果直接作废。另外还会核对事务成功率和回滚率，回滚率异常高说明争用严重，数字不可信；回滚率接近于零反而要警惕，可能是校验逻辑没生效。

5. 一组对照实验的复盘：从曲线异常定位到参数

光讲方法有点干，讲一个我实际做过的对照实验。这个实验里六个库的表现差异，最后追下去发现根因不在数据库本身，而在一个共用的环境参数上。

5.1 实验设计与基线

硬件是同一台机器分时复用，八核处理器、三十二吉内存、固态盘分成数据盘和日志盘。六个库分别部署，每次只跑一个，跑完彻底清理环境再跑下一个。仓库数统一设为二十，虚拟用户数设成两百，爬坡时间五分钟，正式测试二十分钟，检查点间隔三分钟，测试时长取检查点间隔的整数倍。

第一轮的结果很有意思：三个库的 NOPM 在同一个区间，另外三个库明显偏低，偏低的那三个里有两个是大家公认的"高性能"选手。这个结果本身就很反常，我没有急着下结论，而是先去看曲线。

5.2 三条曲线的分叉点

偏低的三条曲线有一个共同特征：前五分钟爬坡正常，第六分钟左右出现一次明显的凹陷，之后再也没有恢复到原来的高度，而是稳定在一个较低的平台。也就是说，这不是慢启动问题，而是某个事件在第六分钟把系统打进了一个低效状态。

第六分钟这个时间点很关键。我对照了后台任务记录，发现那个时间点正好是文件系统的一次批量回写触发窗口。原来那三个库的日志写入模式更倾向于攒批，攒到一定量之后集中刷盘，正好撞上了文件系统的回写窗口，两者叠加导致 IO 队列深度瞬间打满，之后虽然恢复了，但缓冲池里的热数据被挤出去了一部分，命中率下降，平台高度就回不去了。

5.3 定位过程与验证

定位过程分三步。第一步是把三个库的日志写入参数全部改成更平滑的刷盘节奏，重跑，凹陷消失了，平台高度回到正常区间，验证了假设。第二步是把另外三个库也改成同样的刷盘节奏，重跑，结果没有明显变化，说明它们本来就不受这个窗口影响。第三步是单独把文件系统的回写参数调平，不做数据库侧改动，重跑，凹陷同样消失，进一步确认根因在文件系统与写入节奏的叠加。

这个实验给我的教训是：横向对比时，任何一个库的异常都可能来自共用环境，而不是它自身。看到反常结果，第一反应应该是查环境，而不是给数据库下结论。另外，"凹陷之后回不去"这个现象特别值得警惕，它说明系统进入了一个新的稳态，而不是临时波动，这种情况下平均值完全不能代表真实能力。

6. 六种不能拿来对比的结果：高频误读

下面这六种情况，我在别人的报告和自己的早期报告里都见过，每一种都会让结论彻底跑偏。

前三种属于方法层面的错误，后面三种属于口径层面的错误。方法层面的错误靠规范流程就能避免，口径层面的错误需要事先约定好，写进测试方案里，六套环境统一执行。我现在的习惯是在测试开始前先写一份口径说明，把隔离级别、刷盘策略、统计窗口、折算方式全部写清楚，跑完之后任何人都能按这份说明复算。

还有一类隐蔽的误读是拿不同版本的数据库对比。某个库的新版本在某个特性上有大幅优化，旧版本没有，你拿新版本对别人的旧版本，结论就没有意义。版本必须固定，而且要在报告里写明具体版本号。

7. 把跑分结论回迁生产的判断标准

跑分的目的不是排名，是给生产环境的配置和选型提供依据。但跑分环境和生产环境差得远，直接把测试参数抄到生产上，往往适得其反。这一节讲怎么把结论安全地搬回去。

7.1 调优动作的优先级排序

从测试里能提炼出的调优动作很多，但不是每个都值得搬到生产。我的排序原则是：先搬那些在测试中带来确定性收益、且风险可控的动作，再考虑收益不确定的动作。

收益确定、风险低的动作包括：合理的缓冲池大小、合适的日志空间、必要的统计信息更新策略、索引重建。这些动作在任何环境下都是正向的，搬过去基本不会出问题。

收益确定但风险中等的动作包括：调整检查点频率、调整后台任务的触发窗口、调整批量提交的大小。这些动作在测试环境里收益明显，但生产环境的负载特征是变化的，参数设死了可能在别的时段出问题。搬这类动作要配套监控，设好回退方案。

收益不确定、风险高的动作包括：调低隔离级别、关闭持久性保证、大幅调整并发上限。这类动作在测试里能换来漂亮的数字，但在生产里可能带来数据一致性问题和故障恢复问题，我的建议是原则上不搬，除非有非常明确的业务依据。

7.2 哪些参数可以搬、哪些不能搬

有一个简单的判断标准：这个参数的作用是否依赖于特定的数据规模。缓冲池大小、日志空间这类参数，作用和数据量强相关，测试环境的数据量和生产不一样，直接照搬通常偏小，需要按比例放大。检查点频率、后台任务窗口这类参数，作用和时间维度相关，和负载的时段分布强相关，测试环境是持续满负载，生产环境有高低峰，直接照搬会导致低谷期资源浪费、高峰期压力集中。

还有一类参数完全不能搬，就是那些为了测试而临时调整的参数，比如临时放开的文件导入权限、临时关闭的自动清理、临时调大的锁列表。这些参数在测试结束后就应该恢复，搬到生产上就是事故隐患。

我自己的做法是维护一份"参数迁移清单"，每个参数标注三件事：测试值、生产建议值、迁移依据。生产建议值通常不是测试值的直接复制，而是按数据量比例、负载特征做换算后的结果。这份清单会和测试报告一起归档，下次做类似评估时可以直接复用。

最后分享一个我踩过的坑：有一次我把测试环境里一个后台任务的触发阈值直接搬到了生产，测试时这个阈值能有效抑制后台干扰，生产上因为数据量大了一个数量级，同样的阈值导致后台任务长期不触发，死元组堆积了两周才被发现，查询性能已经掉了一半。从那以后，凡是和绝对数据量挂钩的参数，我一律按比例换算，绝不直接复制。跑分给出的是一组相对关系的证据，把它翻译成生产配置，中间那道换算的功夫省不得。