容量基准测试需将结果转化为可执行扩容动作，通过“业务指标-资源指标”映射曲线确定实际吞吐拐点，并据此设定带时间窗口的动态阈值及分层扩容预案。
容量基准测试不是跑完压测脚本就结束，而是要把测试结果翻译成可执行的扩容动作。关键在于用基准数据锚定“什么时候扩、扩多少、扩什么”，而不是凭经验拍板。
用基准数据反推真实承载边界
单次压测得出的峰值QPS、CPU 95%值只是静态快照。真正有用的是把不同负载档位下的资源水位和响应延迟对应起来，画出“业务指标-资源指标”映射曲线。比如：
- QPS 2000时，TiKV节点平均磁盘IO util为65%，P99延迟120ms
- QPS 3500时，同一节点磁盘IO util跃升至92%，P99延迟跳到480ms且开始抖动
- 此时就能判断：3500是该规格节点的实际吞吐拐点，不是理论极限
把拐点转化为扩容触发条件
线上监控不能只盯“CPU > 80%”这种粗粒度阈值。应基于基准测试结论，为每个核心组件设定带时间窗口的动态阈值：
- 当TiKV磁盘IO util连续5分钟 > 85%，且QPS同比上涨超20%，触发水平扩容建议
- 当PD节点CPU > 70%持续10分钟，且etcd raft apply延迟 > 200ms，触发PD节点垂直升级（而非加节点）
- ZooKeeper集群在大促前72小时，若watcher连接数基准值为8000，监控发现当前连接数达6500并呈加速上升趋势，即启动预扩容
结合业务节奏做分层扩容预案
基准数据要嵌入业务周期才有意义。例如电商场景：
- 日常流量下，集群按基准测试中“QPS 1800 + P99
- 大促前48小时，依据历史大促增长倍数（如峰值QPS达日常3.8倍），提前将TiKV节点数按3.8×基准拐点数部署
- 秒杀瞬时波峰（持续约15分钟），不靠扩容扛，而是启用降级开关：关闭非核心日志、限流低优接口、切走报表查询流量
验证扩容效果必须回归基准环境
每次扩容后不能只看监控曲线是否回落，要立即在隔离环境中复现相同基准测试场景：
- 用同一套JMeter脚本、相同比例的读写混合比、相同数据集规模
- 对比扩容前后P99延迟波动范围、错误率、各节点资源饱和度分布
- 若新集群在QPS 4000时P99仍稳定在130ms内，说明扩容有效；若延迟抖动加剧，说明网络或存储IO成为新瓶颈，需针对性优化
基准测试的价值不在报告页数，而在能否让扩容从被动救火变成可计算、可预期、可验证的动作。
