基准测试工具之你不知道的两三事 | 5.什么是读写混合负载
前面的写入负载测试，回答的是一个很基础的问题：当设备持续上报数据时，数据库能否稳定地把数据接收下来。
但在线上环境中，写入通常不是唯一发生的事情。设备持续上报的同时，运维页面要刷新最新状态，趋势图要展示一段时间内的曲线，告警系统还可能统计某些指标。写入与读取在同一段时间内共同发生，这就是读写混合负载。
它并不意味着“把所有查询都打开”。读写混合负载的重点，是用一组能够代表线上行为的写入与查询操作，观察它们会如何相互影响。
1. 什么叫读写混合负载？
纯写负载中，测试程序持续向数据库写入数据；纯读负载中，测试程序只执行查询。读写混合负载则让两者在同一轮测试中并发发生：新的时序数据不断进入系统，同时已有数据被查询。
这张图揭示了一个容易被忽略的事实：线上体验不是单独由写入吞吐量或查询延迟决定的。写入慢会让新数据迟到，查询慢会让页面和告警滞后；两者又可能竞争同一组 CPU、内存、网络和磁盘资源。
2. 它和纯读、纯写有什么不同？
三种负载都很有价值，但它们回答的问题不同。
| 负载类型 | 主要回答的问题 | 适合的阶段 |
|---|---|---|
| 纯写负载 | 数据持续进入时，系统的写入能力和尾部延迟如何？ | 建立写入基线、观察批写和乱序影响。 |
| 纯读负载 | 某类查询在已有数据上的响应速度如何？ | 单独评估趋势查询、聚合或历史回溯。 |
| 读写混合负载 | 查询发生时，写入和查询能否同时保持可接受表现？ | 模拟线上运行、评估资源争用与体验边界。 |
因此，读写混合不是纯写和纯读测试的替代品。更常见、也更可靠的顺序是：先建立纯写基线，再理解关键查询的单独表现，最后用混合负载观察它们放在一起后发生了什么。
3. 为什么不能只看其中一边？
假设一个系统在纯写测试中吞吐量很高，但一旦仪表盘刷新趋势图，写入 P99 明显升高；或者系统写入仍然稳定，页面查询却偶尔等待很久。无论哪一种，都说明纯写结果不足以描述真实线上状态。
读写混合测试的价值就在于发现这种“单独看都不错，放在一起才暴露”的问题。它通常关注三组关系：
- 写入是否受读影响：查询加入后，写入吞吐量、P99 和失败数是否变化？
- 查询是否受写影响：持续写入时，最近点、范围或聚合查询是否仍及时返回？
- 两者是否出现相互挤压：当写入和查询都变慢时，是偶然波动，还是资源竞争已经达到新的边界？
这些问题不要求测试一开始就给出复杂答案。它们的作用，是让我们知道每一轮测试应该重点记录什么。
4. 线上场景如何变成混合负载？
把业务场景翻译成混合负载时，可以先拆成“写什么”和“读什么”两部分。
| 线上动作 | 可抽象出的负载行为 |
|---|---|
| 设备定期上报温度、压力等指标 | 周期性写入，明确设备数、测点数、批大小与上报节奏。 |
| 页面每隔一段时间刷新设备状态 | 最近点查询或最近数据附近的查询。 |
| 页面展示最近一小时趋势 | 固定时间范围查询，明确窗口大小与涉及的设备、测点数量。 |
| 告警触发后汇总某段数据 | 带时间条件的聚合查询。 |
| 夜间生成较大范围的报表 | 更适合单独设计历史读负载，而不是混入实时测试。 |
这里最重要的不是参数本身，而是对应关系是否成立。比如，若页面一次只展示一个设备的几项指标，就不应在测试里直接设置成大量设备、长时间窗口的聚合查询；那样测到的将是另一种业务。
5. 混合不等于越复杂越好
读写混合负载最常见的误区，是把精确点、范围、聚合、倒序等查询一次全部加入。这样的测试看起来很全面，实际却很难解释：写入下降到底是由哪一种查询造成的？查询变慢又是范围太大，还是操作比例太高？
更稳妥的方式是从一个最典型的读请求开始。例如，系统主要是设备状态页，就先以“持续写入 + 最近点查询”作为第一份混合负载；确认结果后，再逐步加入趋势图或聚合统计。
这样做的核心原则是：一次只增加一种新的压力来源。它不仅让测试结果更容易解释，也为后续定位瓶颈留下清楚的对照关系。
6. 一份合格的混合负载，应记录什么？
在混合测试中，只记录一个“总吞吐量”远远不够。至少应分别记录：
- 写入操作的吞吐量、P99 和失败数；
- 每一类查询操作的吞吐量、P99 和失败数；
- 写入与查询的相对比例、查询时间范围和涉及的设备、测点数量；
- 数据库版本、客户端配置、机器环境与完整日志。
这些记录让我们能够回答一个更有意义的问题：在某一种真实读请求加入后，系统牺牲了多少写入能力，换来了怎样的查询体验？这才是读写混合测试应当支持的判断。
7. 小结
读写混合负载描述的是线上最常见的一种状态：数据持续进入系统，同时又被持续读取。它既不是“写入加几个查询”的随意拼接，也不是越复杂越好。
开始设计混合负载前，可以先确认：
- 哪种写入行为是线上持续发生的？
- 哪一种查询最能代表用户或系统的实时需求？
- 写入和查询的结果，是否会被分别记录与解读？
- 新加入的查询，是否有纯写基线可供对照？
当这些问题有了答案，就可以进入下一篇文章：使用 IoT Benchmark 的操作比例、最近数据查询和时间窗口参数，把概念上的读写混合负载落实为可运行的测试配置。
系列文章
- 第一篇：数据库基准测试工具是什么
- 第二篇：从一次时序数据库写入测试开始
- 第三篇：如何模拟线上写入负载
- 第四篇：如何读懂测试结果波动
- 第五篇：什么是读写混合负载
- 第六篇：如何模拟线上读写混合负载
- 第七篇：怎样做一场公平的性能对比
- 第八篇：怎样找到并发与批大小的合理区间
- 第九篇：如何模拟乱序写入
- 第十篇：不同写入接口该怎样比较
- 第十一篇：性能测试与正确性验证有什么区别
- 第十二篇：单机测试与集群测试有什么不同
- 第十三篇：怎样保存和复盘一轮测试
- 第十四篇：一份可复用的基准测试方案模板