一篇博客写"某数据库比某数据库快 3 倍"，配了张漂亮的柱状图。团队据此选了它，上线后发现"3 倍"只在高并发小查询上成立，而自己的场景是大查询低并发——实际落后 20%。
别人的基准是"别人的实验"，而基准的结论永远附在条件上。这个判断有个残酷的前提：基准几乎从不会主动告诉你"它不适用"。所以读的人必须自己做"条件匹配"，而这一步通常被跳过——因为文章的结构是"结论在前、方法在后"。
判断能不能信，不是看"谁做的"，而是看"条件写清了吗、以及我的条件是否落在里面"。
1. 五个必看项
| 项 | 缺了意味着 |
|---|---|
| 硬件与环境 | 无法判断是否可比 |
| 数据规模与分布 | 结论只在特定规模成立 |
| 负载形态 | 单线程不能外推并发 |
| 测量方式（含不含网络/预热） | 数字含义不明 |
| 版本与参数 | 默认值可能已变 |
第四项最常缺："QPS 8000"是单机还是集群、含不含 TLS、是否 keep-alive，这三件事不写清就无法比较。
第五项在"数据库对比"里尤其关键：同一个数据库的两种配置可以差一个数量级第四项还应当看"计时点"：是从"发请求"到"收完响应"，还是只算服务端处理。两者可能差一倍，而它们都自称"延迟"。
，而"我用默认参数"这句话本身就是一个重大变量。
2. 三个立刻可疑的信号
| 信号 | 可疑点 |
|---|---|
| 只有柱状图没有数字 | 无法核对 |
| 单一场景横扫全部 | 不符合物理常识 |
| 没有"什么时候会更差" | 缺失效边界 |
第三项的判据可以更硬一点：看它有没有一篇"对方也很快"的段落。有，说明作者测过对手的强项；没有，说明他可能只测了自己擅长的场景。
第三项是最强的判断依据：一份可信的基准一定会写"在什么情况下对方更快"。只写"我的方案全面胜出"的，通常是测了对自己有利的场景。
第二项也直接：不同数据库各有擅长场景，"A 在所有场景都比 B 快 3 倍"要么是测错了，要么是 B 用了不合理配置。
// 一份可信基准的最小结构（五段）
1 问题：要回答什么（如"小查询高并发下的 P99"）
2 环境：机器、OS、版本、参数（含非默认项）
3 数据：行数、字段、分布、预热方式
4 方法：负载形态、并发模型、轮次、计时点
5 结果与边界：数值 + "什么情况下结论反转"
// 缺第 5 段的基准，只能当参考，不能当依据
还有一个"样本偏差"的来源：厂商基准。它的典型形态是"我们优化了 X，因此在我们的测试里快 N 倍"，而测试集本身是按 X 的特性挑的。判断方法是看"测试集的来源"——是公开标准集，还是自建。
// 三类基准的可信度排序（不是绝对）
1 第三方 + 公开数据集 + 有脚本 → 最可信
2 厂商 + 自建集 + 有脚本 + 写了边界 → 可参考，需复现
3 厂商 + 自建集 + 只有柱状图 → 当广告看
// 判据：能否独立复现 + 是否写了失效场景
3. 复现成本与判断顺序
| 步骤 | 成本 |
|---|---|
| 读条件是否齐全 | 五分钟 |
| 找作者原始脚本 | 十分钟 |
| 在自己的环境跑一次 | 半天到两天 |
| 完整复现其场景 | 数天 |
判断顺序应当从便宜到贵：先看条件全不全（五分钟），再看有没有脚本（十分钟）。多数"可疑基准"在第一步就能排掉。
第三项是可选的：只有当"这次选择代价高"时，才值得花半天复现。第二项（找脚本）是最被低估的一步：有脚本说明作者欢迎复现，也会暴露他没写出来的参数。而没有脚本的基准，其方法段往往是事后补写的。
选一个数据库 vs 选一个日志库，代价不同。
4. 数字该怎么读
| 写法 | 解读 |
|---|---|
| "快 3 倍" | 相对值，基准是什么 |
| "8000 QPS" | 绝对吞吐，条件是什么 |
| "P99 从 120ms 到 40ms" | 分位改善，均值可能没变 |
| "延迟降低 60%" | 从多少降到多少 |
第四项（"延迟降低 60%"）要看"基数"：从 500ms 降到 200ms 是 60%，从 5ms 降到 2ms 也是 60%，而后者在业务上等同于"没感觉"。
第一项的"基准是什么"极关键："快 3 倍"可能是"从 300ms 到 100ms"，也可能是"从 3ms 到 1ms"——后者对多数场景毫无意义。
第三项要区分分位与均值：P99 改善而 P50 不变，说明改的是长尾，这与"整体变快"是不同结论。
// 同一个"3 倍"的三种含义
A: 300ms → 100ms 对交互式场景显著
B: 30ms → 10ms 对批量场景几乎无感
C: 3ms → 1ms 只在超高频调用里有意义
// 结论：相对值必须配"绝对值"才能判断
读的时候还要注意"平均值陷阱"在基准里的两种表现：只报平均吞吐（长尾不可见）、只报总耗时（把分位差异抹平）。而多数线上问题出在长尾，不在均值。
// 同一组数据，两种报法的差异
均值：120ms → 看起来很好
P50 40ms / P99 900ms → 长尾极差（1% 用户在等 0.9 秒）
// 对"用户体验"来说，后者才是真相
5. 把基准用于决策的三步
| 步骤 | 动作 |
|---|---|
| 1 抽出条件 | 硬件、规模、负载 |
| 2 匹配自己的场景 | 哪几项相同、哪几项不同 |
| 3 只信"匹配部分"的结论 | 其余当假设 |
第三项是最重要的纪律：**当你的场景与基准不同时，基准的数字只是"一个假设"**第二步（匹配场景）要具体到"三个维度"：数据量级、请求形态（点查/聚合）、并发模型。三项里有两项不同，这个基准基本不能用来做决策。
，需要自己验一次。
实践中常见的错误是"用一个不同场景的基准支撑决策"，而它在复盘时表现为"当初那个测试是这么说的"。
最后一步"自己验"也有成本控制技巧：只复现"关键的那一项"。比如你要判断"聚合查询是否更快"，就只测这一个查询，不必复现整套测试。这一项通常半小时能做完，而它决定了"3 倍"在你的场景里是 3 倍还是 0.8 倍。
// 单项复现的最小流程（30 分钟）
1 用你的真实数据（或同规模副本）
2 只跑那一条查询，各 20 次
3 记录 P50/P99 与 QPS
4 与基准数字对比，写一句"在我的场景里是 X 倍"
// 关键：不做完整基准，只做"是否支持这个决策"的最小验证
6. 排错：五种"信了不该信的基准"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 上线后慢 20% | 场景不匹配 | 匹配后再信 |
| 配置不同导致的差异 | 默认参数 | 核对参数 |
| 单机数字当集群用 | 负载形态不同 | 看并发模型 |
| 只看均值 | 长尾未测 | 看分位 |
| 复现不出来 | 缺预热/缓存 | 读方法细节 |
第五项（复现不出来）最常见的原因是"数据在缓存里"：作者的第一次跑是冷的、后续是热的，而文章引用的是热的那个数。而你的场景可能是冷启动。
第一项的典型是"小查询 vs 大查询"：基准测的是点查，你用的是聚合，两者瓶颈不同（前者 IO，后者 CPU/内存）。
7. 边界：什么情况不必细究
| 场景 | 为什么 | 做法 |
|---|---|---|
| 数量级差异（10 倍以上） | 噪声不影响方向 | 可粗信 |
| 只做"是否可行"的判断 | 不需要精确 | 粗信 |
| 自己马上要实测 | 别人的只是参考 | 粗信 |
| 决策代价很低（可换的库） | 换回来便宜 | 粗信 |
判断口径一句话：这次决策的"试错成本"有多高。最后一条与"引用"有关的边界：引用别人的基准时，要把条件一起写下来。只写"某基准显示快 3 倍"是把对方的方法段落丢掉了，而下一个读你的人会重复你犯的错。
高（数据库、消息中间件），就必须自己复现关键场景；低（日志库、工具库），粗信即可。
8. 自测
- 五个必看项里，哪一项最常缺失？"含不含网络/TLS"为什么必须写清？
- 三个可疑信号里，哪一个是最强的判断依据？为什么"全面胜出"不可信？
- 判断顺序为什么应当"从便宜到贵"？什么情况下值得花半天复现？
- "快 3 倍"为什么必须配绝对值？"P99 改善但 P50 不变"说明什么？
- "只信匹配部分的结论"这条纪律的含义是什么？违反它会怎样？
- 判断"是否需要细究基准"的那个问题是什么？