一辆车在封闭赛道跑得快，不代表它适合每天堵车通勤。数据库基准也一样：每秒完成 50,000 次操作，只说明系统在某组条件下达到这个数字。数据是否已在缓存里、请求是否贴近真实业务、错误和重试有没有计入，都会改变结果的含义。吞吐量——单位时间完成的操作数——既不告诉你单次请求要等多久，也不说明用了多少机器、花了多少钱。
Ananth Packkildurai尤其提醒一种容易漏掉坏消息的测试：客户端发出请求后，必须等响应回来才继续。系统一旦卡顿，客户端也随之少发请求，于是本该排队的请求没有进入统计，最慢时刻反而显得不那么慢。更可靠的做法，是同时报告计划发出的负载、实际完成的吞吐量、错误率、成本和延迟分布，尤其关注第 99 百分位等尾延迟。说白了，基准分数是一条观察，不是架构答案；只有测试的数据规模、读写比例、并发方式和缓存状态接近生产环境，它才真正有选型意义。