新系统压测吞吐量高40倍，不代表业务能承受40倍增长

用基准测试做容量规划时，一个看起来合理、实则危险的推断方式 是：先测老系统的TPS（每秒事务数），再测新系统的TPS，发现新 系统是老系统的40倍，于是直接推断”新系统能支撑40倍的业务增长”。 这个推断的问题在于它把”系统吞吐量的倍数”和”业务规模的倍数” 划了等号，但业务真实增长时，变化的从来不只是请求数量本身： 用户数、数据量、以及不同数据之间的交互关系都会同时膨胀，而 这些维度不可能都恰好按同一个倍数（40倍）增长——数据量涨了， 索引和缓存命中率的行为会变；用户数涨了，数据分布和访问热点 可能完全不同；而且当业务真的增长到当初设想的规模时，应用本身 的功能也早就迭代过了，新上线的特性可能对数据库造成远超原有 功能的压力。这些压力、数据、关系和特性的变化本身就很难被 基准测试提前模拟出来，因此也很难被准确评估。这条经验教训的 本质是：基准测试测出的是”系统在当前这一组固定条件下的处理 能力上限”，而业务增长是一个多维度同时变化的过程，用一个单一 维度（吞吐量倍数）的测试结果去外推一个多维度变化的未来，注定 会得出过于乐观的结论——基准测试能帮你估出”系统大致的余量有 多少”，但不能替你回答”业务能不能长到某个具体规模”这个问题。