容量规划与压测

「这台库能扛多少？」不能靠猜。压测给出基线，容量规划据此推算可承载规模，并预留增长与故障余量。

关键指标

指标	含义	关注点
QPS / TPS	每秒查询/事务数	吞吐上限
延迟 P50/P95/P99	分位响应时间	平均会掩盖长尾，看 P99
并发连接数	同时活跃的连接	与池上限、`max_connections` 对齐
CPU / IO 利用率	资源饱和度	哪个先到 100% 就是瓶颈
磁盘 IOPS / 吞吐	物理读写能力	SSD/云盘规格决定上限
缓存命中率	Buffer Pool / Redis	命中率骤降会击穿到磁盘
错误率	超时、失败比例	过载的早期信号

Tip

压测要区分吞吐（throughput）与延迟（latency）：系统在达到吞吐峰值后继续加大并发，吞吐不会上升，延迟却会急剧恶化。容量规划应取「延迟仍可接受」的拐点，而非绝对峰值。

常用压测工具

工具	目标	特点
sysbench	MySQL / PostgreSQL	内置 TPCC 类 OLTP 场景，最常用
pgbench	PostgreSQL	官方自带，简单可靠
redis-benchmark	Redis	官方自带，覆盖各命令
YCSB	多种 NoSQL/关系型	通用基准框架
mongoperf / mongo-perf	MongoDB	官方性能工具
wrk / k6 / vegeta	HTTP 层	端到端压测应用

sysbench（MySQL / PostgreSQL）

# 准备 10 张表、每张 100 万行
sysbench oltp_read_write \
  --db-driver=mysql \
  --mysql-host=127.0.0.1 --mysql-user=app --mysql-password=*** --mysql-db=demo \
  --tables=10 --table-size=1000000 \
  --threads=64 --time=300 --report-interval=10 \
  prepare

# 运行
sysbench oltp_read_write \
  --db-driver=mysql --mysql-host=127.0.0.1 --mysql-db=demo \
  --tables=10 --table-size=1000000 \
  --threads=64 --time=300 --report-interval=10 \
  run

# 清理
sysbench oltp_read_write --mysql-db=demo --tables=10 cleanup

关注输出中的 transactions per sec、queries per sec、以及 95th/99th percentile latency。

pgbench（PostgreSQL）

# 初始化（scale=100 约 1000 万行）
pgbench -i -s 100 -h 127.0.0.1 -U app demo

# 压测：64 个客户端、16 个并发线程、跑 5 分钟
pgbench -c 64 -j 16 -T 300 -h 127.0.0.1 -U app demo

# 自定义脚本（贴近真实 SQL）
pgbench -c 64 -j 8 -T 300 -f ./my_script.sql -h 127.0.0.1 -U app demo

redis-benchmark（Redis）

# 覆盖常用命令，50 个并发、共 10 万请求
redis-benchmark -h 127.0.0.1 -q -n 100000 -c 50

# 指定命令与数据大小（pipeline 提升吞吐）
redis-benchmark -t get,set -n 1000000 -c 100 -d 512 -P 16 -q

Warning

redis-benchmark 不加 -r 时会对同一个 key 反复操作，结果偏乐观。用 -r 1000000 随机 key 更接近真实；-P（pipeline）会大幅放大吞吐，评估时应按实际客户端是否使用 pipeline 来决定是否加。

容量估算

已知：单机在目标延迟下的吞吐基线 T（如 8000 QPS）
     业务峰值 QPS = P，未来增长按年 g%，预留余量系数 r（1.3~1.5）

所需实例数 = ceil( P × (1+g)^n × r / T )

连接数约束： 实例数 × 每实例最大连接数 < 数据库 max_connections × 0.8

示例：业务峰值 20000 QPS，单机基线 8000 QPS，预留 1.4 倍，则至少需要 ceil(20000×1.4/8000)=4 个读实例（考虑读扩展），并通过缓存进一步卸压。

Tip

容量规划优先「降负载」而非「加机器」：加索引、加缓存、优化 SQL、归档冷数据，往往比扩容更省成本。只有当单机确实达到瓶颈时，才进入主从扩展与分片。

压测注意事项

数据量要接近真实：空表或小表的索引行为完全不同，应在准生产数据量下测。
先预热：让 Buffer Pool / Redis 缓存热起来再采集，否则测到的是冷启动。
不要在生产测：压测会打满资源，应在独立环境或低峰用影子流量。
逐层定位瓶颈：CPU、内存、磁盘 IOPS、网络、连接数，找到第一个饱和项。
关注长尾与稳定性：持续压测一段时间，观察延迟是否随时间劣化（内存泄漏、膨胀）。
端到端也要测：数据库快不代表应用快，HTTP 层压测能暴露连接池、序列化等问题。

小结

压测建立基线，容量规划据此推算实例数与连接数上限。
看 P95/P99 与资源饱和度，取「延迟可接受的拐点」为容量。
sysbench / pgbench / redis-benchmark 分别覆盖三大数据库的基准场景。
真实数据量、预热、非生产环境、逐层定位瓶颈是压测的关键。
优先降负载（索引/缓存/归档），再考虑扩容。

#容量规划与压测

#关键指标

#常用压测工具

#sysbench（MySQL / PostgreSQL）

#pgbench（PostgreSQL）

#redis-benchmark（Redis）

#容量估算

#压测注意事项

#小结