数据库吞吐怎么测？香港金牌5115服务器（10核20线程、32GB DDR4）评测方法

数据库吞吐不能只看每秒完成多少笔事务：吞吐上升时，延迟可能同步恶化；并发增加后，CPU、内存或磁盘也可能先到瓶颈。评测香港金牌 5115 服务器（10 核 20 线程、32GB DDR4），应把吞吐、延迟分位数、并发、资源占用和香港网络往返时间放在同一组测试条件下观察。

这类评测的目标不是给出脱离业务的“固定性能分数”，而是判断服务器在指定数据库、数据集、读写比例和连接数下，能否持续承载目标负载。以下方法提供可复现的测试框架和示例判断方式；文中的示例数据用于解释分析方法，不代表该服务器的实测结果。具体表现还取决于存储介质、数据库配置、操作系统、网络路径和实例交付规格。

一、先确定测试要回答的问题

开始压测前，先把业务负载描述清楚。数据库可能是读多写少的查询服务，也可能是高频写入、事务更新或混合读写；同一台服务器在不同负载下的结果并不相同。测试前至少记录以下信息：

• 数据库及版本、操作系统与内核版本、文件系统、存储类型和可用容量。
• 数据集大小、表数量、索引情况，以及数据是否能够放入内存。
• 读写比例、事务类型、单次事务操作数、连接池大小和目标并发数。
• 测试端与服务器的位置、网络往返时间（RTT）、是否经过公网，以及测试时段。
• 数据库参数、缓存设置、日志和持久化策略，以及是否与其他业务共享资源。

10 核 20 线程说明处理器具备 10 个物理核心、20 个逻辑线程，但不能简单等同于 20 个独立核心。线程数有助于同时处理多个任务，数据库事务的实际执行能力仍受单线程性能、锁竞争、缓存命中率、存储延迟等因素影响。32GB DDR4 则是内存容量信息，不等于数据库可使用全部内存，也不能单独说明内存带宽或延迟。操作系统、数据库连接、缓存和其他服务都要占用内存，测试时应观察可用内存和交换空间，而不是只看标称容量。

二、指标分别代表什么

吞吐：单位时间完成了多少工作

数据库吞吐常见单位包括事务每秒（TPS）、查询每秒（QPS）或操作每秒（ops/s）。比较结果时，必须确认统计对象一致：一个事务可能包含多条 SQL，一个压测工具的“操作”也未必等于一笔业务请求。

吞吐更适合回答“在当前负载和配置下完成工作有多快”，不应脱离延迟单独判断。若增加并发后吞吐几乎不再增长，而响应延迟持续上升，通常表示系统已接近某种资源瓶颈，继续加连接未必能提升有效处理能力。

延迟：一次请求需要等待多久

平均延迟容易掩盖尾部慢请求。建议至少记录平均值、中位数、P95 和 P99：

• P95 为 95% 的请求在该延迟以内完成。
• P99 为 99% 的请求在该延迟以内完成。
• P99 对锁等待、磁盘抖动、检查点和网络波动较敏感，适合观察少数慢请求。

延迟要明确统计范围。压测工具记录的端到端时间可能包含客户端排队和网络往返；数据库内部执行时间则可能不包含这些部分。两者不能直接混为一谈。对香港服务器而言，若应用不在香港，网络 RTT 可能占请求延迟的显著比例。数据库本身执行很快，并不必然意味着远端应用看到的整体响应也快。

并发：同时存在的工作量，不等于有效吞吐

并发连接数表示同时提交或等待处理的会话规模，不表示这些会话都在并行执行有效计算。连接数过少可能无法形成足够负载；过多则可能增加线程调度、锁竞争、内存消耗和队列等待。

因此应按阶梯测试并发，例如 1、2、4、8、16、32、64，而不是只测一个高并发点。观察每一级吞吐和 P95/P99 延迟的变化，找到吞吐开始趋平、尾延迟明显抬升的区间。业务连接池的上限应结合这个区间设置，而不是直接把压测工具的最大并发数当作推荐连接数。

CPU、内存与 I/O：判断瓶颈位置

CPU 使用率需要与吞吐和延迟结合解读。CPU 接近饱和且吞吐不再增加，可能意味着计算或数据库执行阶段达到上限；CPU 不高但延迟很高，则应继续检查磁盘等待、锁、网络、连接池和数据库内部队列。高 CPU 也可能来自压测客户端自身，应在客户端和服务器两侧分别观察。

内存指标要区分已用、可用、缓存和交换活动。Linux 会利用空闲内存作为文件缓存，因此“已用内存高”本身不能证明内存不足。持续发生交换读写、可用内存长期偏低，并伴随查询延迟上升，才更值得关注。还要确认数据库的缓冲池是否按预期配置，避免把操作系统缓存和数据库缓存重复计算。

磁盘 I/O 至少关注读写吞吐、IOPS、平均等待时间、队列长度和设备利用率。数据库事务日志的同步写入、数据页随机读写和批量扫描，对存储的要求不同。单看顺序读写速度，不能代表数据库混合读写性能；只看设备利用率，也不能说明具体请求的等待时间。存储型号、云盘或本地盘规格、共享与否等信息若未确认，就不宜据此推断数据库 I/O 上限。

三、测试变量与采样方法

建立可复现的测试环境

尽量使用独立测试实例和专用测试库，不要直接对生产库做高并发压测。压测会消耗 CPU、内存、磁盘空间和 I/O 带宽，也可能产生大量数据、日志或临时文件。运行前确认测试数据可丢弃、磁盘空间充足，并限制测试时长与并发上限；若与线上业务共享主机或存储，应安排维护窗口并设定停止条件。

测试数据应足以代表目标业务。数据集远小于数据库缓存时，结果可能主要反映内存命中；数据集明显大于可用缓存时，磁盘读写的影响会更突出。可分别进行内存友好型和超出缓存容量的测试，但要明确标注数据集与缓存关系，不能把两种结果当成同一场景。

固定数据库版本、配置和压测参数，每次只改变一个主要变量。例如先固定读写比例和数据集，只调整并发；随后固定并发，再比较不同读写比例。每轮测试先预热，再进行稳定阶段，并至少重复多轮。记录测试开始与结束时间，避免把启动阶段、缓存预热或短时峰值当成稳定吞吐。

分阶段施加负载

可以采用“基线—阶梯并发—稳定运行—恢复检查”的流程：

1. 记录空闲状态的 CPU、内存、磁盘和网络指标，并检查数据库错误日志。
2. 从低并发开始，逐步增加并发，每一级运行到指标稳定后再记录结果。
3. 在候选业务并发下持续运行一段时间，观察吞吐、尾延迟和资源是否随时间恶化。
4. 停止压测后确认资源恢复、数据库无异常，检查测试期间是否出现错误、超时或重试。

每级测试可运行数分钟，稳定阶段可延长到 15—30 分钟作为示例起点；实际时长应根据业务周期和存储缓存特性调整。持续测试尤其重要：短测可能尚未触发日志刷盘、检查点或缓存淘汰，不能充分体现长期运行状态。

采集主机与数据库指标

Linux 上可用 vmstat 和 iostat 观察系统资源。若系统未安装 sysstat，先按对应发行版的运维规范安装；不要在生产主机未经评估就修改系统软件。

vmstat 1
iostat -xz 1

vmstat 中的运行队列、空闲 CPU、等待 I/O 和交换活动可帮助判断系统压力；iostat -xz 可观察设备吞吐、等待时间、队列和利用率。字段名称及含义可能随系统版本和工具版本略有差异，应结合本机手册解释。需要定位进程时，可用 pidstat 按进程采样 CPU、内存和 I/O；如果没有该命令，先确认工具包来源和适用版本。

数据库侧则应记录连接数、活动会话、锁等待、事务提交与回滚、缓存命中、日志刷新、检查点、慢查询和错误数。MySQL 可结合性能模式及状态变量，PostgreSQL 可结合统计视图、活动会话和日志。指标名称会随数据库版本与配置变化，采样前先确认对应版本的文档和权限要求。单看主机利用率无法判断数据库内部是否卡在锁等待或连接队列。

用基准工具时标明边界

sysbench 可用于 MySQL 兼容数据库的事务负载测试，但它产生的是工具定义的工作负载，不等于任意真实业务。下面示例只适用于专用测试库；请先确认目标主机、数据库名和账号。初始化会创建测试表并写入数据，可能消耗较多空间和 I/O，禁止直接指向生产库。

sysbench oltp_read_write \
  --db-driver=mysql \
  --mysql-host=DB_HOST \
  --mysql-port=3306 \
  --mysql-user=TEST_USER \
  --mysql-password=TEST_PASSWORD \
  --mysql-db=bench_db \
  --tables=8 \
  --table-size=100000 \
  prepare

完成初始化后再进行阶梯测试。每次改变并发数时保留其他参数不变，并把完整命令、工具版本和输出保存下来：

sysbench oltp_read_write \
  --db-driver=mysql \
  --mysql-host=DB_HOST \
  --mysql-port=3306 \
  --mysql-user=TEST_USER \
  --mysql-password=TEST_PASSWORD \
  --mysql-db=bench_db \
  --tables=8 \
  --table-size=100000 \
  --threads=16 \
  --time=300 \
  --report-interval=10 \
  run

上述 --threads=16 和数据规模只是示例，不是这台服务器的推荐配置。测试参数应按实际数据集、连接池和目标事务模型调整。密码写在命令行可能进入 shell 历史或进程信息；正式测试宜采用受控凭据文件、环境变量或其他符合本地安全规范的方式，并限制测试账号权限。测试结束后的清理操作会删除测试数据，应先核对数据库名和实例，确认没有误指向生产环境，再按数据库管理员的备份与回滚流程处理。

四、怎样解释一组测试结果

下表中的数据是用于演示分析方法的假设示例。它说明指标之间可能出现的关系，不代表香港金牌 5115 服务器的测量结果。

这组示例中，线程从 16 增加到 32 后，吞吐只小幅变化，P95 却明显抬升。如果真实测试也出现类似趋势，合理的初步判断不是“32 并发性能更强”，而是系统已接近瓶颈，增加并发主要带来排队。下一步应联合观察 CPU、I/O 等待、锁等待和数据库队列，确定瓶颈来自计算、存储还是事务冲突。

不同指标的组合可以进一步缩小判断范围：

• 吞吐趋平，CPU 接近饱和，I/O 等待不高：优先检查查询执行、单线程瓶颈、索引和 CPU 调度；也要排除压测客户端成为瓶颈。
• CPU 不高，P95/P99 较高，磁盘等待或队列上升：检查存储延迟、随机读写、日志同步和检查点行为，并确认是否有其他实例共享存储。
• 吞吐下降，数据库锁等待或死锁增加：检查事务长度、更新热点、索引设计和并发写入模式；单纯增加连接数通常无法解决锁竞争。
• 服务器指标平稳，但客户端端到端延迟明显偏高：对照服务器内部执行时间和客户端 RTT，排查香港以外的网络路径、客户端排队和连接建立开销。
• 短测表现正常，长测逐渐变慢：关注缓存容量、内存交换、日志增长、检查点、温度或资源限额等随时间变化的因素。

吞吐与延迟的关系也应按业务目标解释。例如，某项任务在低并发时延迟很低，但每秒处理量不足以消化业务峰值；另一项任务的峰值吞吐较高，却只有在长尾延迟远超服务目标时才达到。两者都不能只凭单一数字下结论。应先确定业务可接受的 P95/P99，再寻找满足延迟约束时的稳定吞吐，而不是把极限压测的最高 TPS 当成日常容量。

五、香港节点测试中的网络变量

香港服务器的数据库性能测试还应区分“主机内性能”和“跨网络访问体验”。若压测客户端与数据库服务器不在同一网络环境，测试结果会混入公网 RTT、路由变化、丢包和客户端带宽等因素。建议把客户端位置、运营商或网络出口、测试时段和连接方式记录下来；条件允许时，分别进行近端主机测试与真实业务来源测试。

对数据库而言，短小且频繁的请求尤其容易受到 RTT 影响。即使数据库每次执行只需较短时间，应用与数据库之间多次往返也会累计等待。因此，网络延迟高时，批量操作、合理使用连接池和减少不必要的往返可能比增加服务器线程更有效。反过来，网络 RTT 较低也不能证明磁盘或数据库内部没有瓶颈。评测报告应将服务端处理时间、客户端观察到的端到端时间和网络 RTT 分开记录。

如果需要测量数据传输，必须同时注明方向和单位。MB/s 表示每秒兆字节，Mb/s 表示每秒兆比特；十进制口径下，1 MB/s 等于 8 Mb/s。网络带宽测试不等于数据库吞吐测试，不能用带宽数值直接推算事务处理能力。

A5数据为数据库与业务后台提供香港物理服务器资源，涵盖Xeon Gold和AMD EPYC平台，搭配不同容量的内存及SSD、NVMe存储，为事务处理、数据缓存和读写负载提供硬件基础。香港产品提供CN2与国际带宽方案，衔接跨境应用的网络需求；不同计算与存储档位也为数据库独立部署、应用与数据库分层及业务扩容提供资源选择。

六、结果如何转化为容量判断

容量判断应基于业务目标和留出的余量，而不是硬件参数本身。可把“满足目标延迟时的稳定吞吐”作为基准容量，再按预期峰值、业务增长和共享资源情况留出空间。比如，业务峰值需要 300 TPS，而测试显示只有在 P95 超出服务目标后才能达到 300 TPS，那么该配置在当前测试条件下就不能视为满足要求；若测试在目标延迟内稳定高于峰值，并在持续运行期间没有错误和资源恶化，才有进一步评估的依据。

一份可复核的评测记录至少应包括：

• 实例规格、存储类型与容量、数据库版本和关键配置。
• 测试数据规模、读写比例、并发阶梯、每轮时长和预热方式。
• 每级的吞吐、平均延迟、P95、P99、错误数和超时数。
• CPU、内存、交换、磁盘吞吐与等待、数据库连接和锁等待。
• 客户端位置、网络 RTT、测试时间及压测工具版本。
• 多轮结果的差异，以及是否存在其他业务或资源争用。

如果重复测试结果差异较大，应先检查测试条件是否一致，而不是简单取最高值。存储缓存状态、后台任务、数据库检查点、网络路径以及主机资源争用都可能造成波动。测试报告应展示稳定区间和异常点，并说明异常是否纳入统计。

七、适用范围与复测条件

10 核 20 线程、32GB DDR4 的香港服务器是否适合数据库负载，取决于查询模型、数据规模、存储配置和客户端位置。它可以作为中等规模业务的候选配置进行评估，但仅凭处理器和内存参数，不能确认具体 TPS、延迟或可承载用户数。若业务以大数据集随机读写、重型分析查询或高频同步提交为主，存储性能和数据库设计可能比核心数量更早成为限制；若负载主要受远端网络往返影响，升级 CPU 也未必显著改善端到端响应。

当数据库版本、存储、配置、数据集、并发模型或应用所在区域发生变化时，应重新测试。扩容前后还应使用相同的数据规模、事务模型、预热时间和采样周期比较结果，并同时检查延迟分位数与错误率。只有在目标负载下持续满足业务延迟要求、资源有可解释的余量且测试结果可重复，才能把压测结果作为容量规划依据。