数据量对性能测试的影响
数据量是性能测试里最容易被低估的变量：空库或千行级数据下跑出来的漂亮数字，换到生产量级往往完全失效——索引选择性变差、分页越翻越慢、统计信息过期、缓存命中率骤降。有效的性能结论必须声明数据量级，并在接近生产的规模下复测关键场景，否则只是验证了功能能跑通。
基本信息
| 量级选择 | 至少覆盖生产当前量级与一两年的增长预估 |
|---|---|
| 数据分布 | 按真实业务分布造数：热门与冷门数据比例要接近现实 |
| 关键节点 | 索引失效的临界行数、分页深度、联合查询的数据倾斜点 |
| 配套维护 | 统计信息定期更新，压测前重建，避免优化器误判 |
| 声明要求 | 报告里写明数据量、分布与生成方式，结论才可复制 |
| 成本控制 | 全量级压测成本高时，锁定核心表按比例放大 |
典型使用场景
- 新系统容量评估：上线前按增长预估造数，验证三年内的承载能力。
- 慢查询复现：生产偶发超时在小数据环境复现不了，放大数据量贴近真实。
- 索引评审：数据量大时验证索引是否被优化器选中，避免上线后全表扫描。
- 分页与导出：深分页与大批量导出是数据量敏感功能，需要专项验证。
- 回归对比：每次压测固定数据量级，保证历史结果可比。
数据量不足时的失真
| 现象 | 小数据下的假象 | 大数据下的真实 |
|---|---|---|
| 查询计划 | 走索引一切正常 | 优化器改走全表扫描 |
| 分页性能 | 深分页瞬间返回 | 越翻越慢拖垮数据库 |
| 缓存命中 | 几乎全命中 | 穿透增加缓存压力 |
| 写入吞吐 | 索引少写入飞快 | 索引维护成本显现 |
| 并发冲突 | 少见锁竞争 | 热点行更新排队 |
数据来源也要声明：生产脱敏、脚本生成还是手工构造，不同来源的分布差异很大。
别忘了增量：测试期间持续写入与清理的节奏会影响缓存与索引状态，与真实系统更接近。
压测数据与其他团队要隔离：在共享环境灌入大量数据，会影响他人的测试与结论。