数据库基准的谎言：为什么快不等于对

数据库选型时，工程师最常做的事就是翻基准测试报告。TPC-C、YCSB、Sysbench 等基准跑出来的吞吐量数字看起来客观公正，是选型时最有说服力的依据。然而，这些数字在真实生产环境中往往失去意义，原因藏在基准测试的运行方式、数据分布和硬件配置里，盲目信任会带来严重后果甚至选型失误。

基准测试通常使用均匀分布或固定模式的合成数据，而真实业务数据往往高度倾斜。比如电商系统的商品表里，百分之八十的查询集中在百分之二十的热门商品，社交网络的用户关系图呈现幂律分布。基准测试跑出来的数字和真实负载之间可能差几个数量级，量级差异比性能本身更关键，长尾场景尤其如此。

基准测试倾向于运行简单、重复的查询，比如单点读取或范围扫描。但生产环境的查询复杂得多，包括多表 JOIN、子查询、事务嵌套、并发更新。基准测试跑得最快的数据库，在真实业务里可能因为锁竞争或执行计划选择不当而崩溃，简化测试掩盖了真实风险，多表关联场景尤其明显，复杂业务尤其要警惕。

基准测试报告通常不会披露完整的硬件配置细节。CPU 型号、内存带宽、磁盘 IOPS、网络拓扑都会显著影响测试结果。一台搭载最新 NVMe SSD 的测试机和云上虚拟机的性能差距可能达到十倍以上，跨云厂商对比更是毫无意义，硬件清单缺失会让结论失去参考价值，跨平台迁移时尤其要谨慎。

选型时应该建立内部基准测试框架，用真实业务数据子集和生产查询日志做回放测试。关注 p99 延迟而非平均吞吐量，关注长尾查询而非峰值性能，关注故障恢复时间而非正常运行指标。基准测试报告只能作为初筛，最终决策必须基于自家业务的实测数据，这才符合工程严谨性，也是避免翻车的关键。