4. 数据库压测方法论：负载模型、基准测试、压力测试、稳定性测试

数据库压测不是简单的“发请求看 QPS”，而是一套从业务理解到风险验证的完整工程方法。本章围绕四个核心维度展开：负载模型决定“测什么”，基准测试建立“对比基线”，压力测试寻找“极限拐点”，稳定性测试验证“长期耐受”。

4.1 负载模型：压测的“业务翻译器”

负载模型是将真实业务流量抽象为压测脚本与参数配置的过程。错误的负载模型会导致压测结果与生产表现完全脱节。

4.2 基准测试：建立“健康基线”

基准测试（Benchmark）是在可控环境下，使用标准化负载对数据库进行性能摸底，目的是获得一组可重复的性能基线数据。基准测试不追求“压垮系统”，而是回答“当前配置下，系统正常能跑多快”。

4.2.1 常用基准测试工具

4.2.2 基准测试执行步骤

1. 环境准备：确保数据库、压测机、网络处于稳定状态，关闭非必要后台任务。
2. 预热：使用低并发运行 5-10 分钟，让 buffer pool 填充到稳定状态。
3. 基线采集：以固定并发（如 50）运行 15 分钟，记录 TPS、QPS、平均延迟、P99 延迟。
4. 数据记录：将结果写入版本化文档，标注数据库版本、配置参数、压测机规格。

4.3 压力测试：寻找“性能拐点”

压力测试（Stress Test）通过逐步增加负载，观察数据库在超过设计容量时的行为。核心目标是找到性能拐点——即 TPS 不再线性增长、延迟急剧上升的临界并发数。

4.3.1 压力测试关键指标

4.3.2 阶梯加压策略

# sysbench 阶梯加压示例（并发从 10 到 500）
for concurrency in 10 50 100 200 300 500
do
    sysbench oltp_read_write \
        --threads=$concurrency \
        --time=120 \
        --report-interval=10 \
        run >> result_${concurrency}.log
    sleep 30   # 冷却时间，让数据库恢复
done

4.4 稳定性测试：验证“长期耐受”

稳定性测试（Soak Test / Endurance Test）在接近生产峰值的负载下，持续运行 4-24 小时，观察数据库是否存在内存泄漏、连接泄漏、磁盘增长、性能衰减等问题。

4.4.1 稳定性测试检查清单

4.4.2 稳定性测试通过标准

• TPS 波动：每 10 分钟平均 TPS 波动不超过 ±15%。
• 延迟趋势：P99 延迟在测试期间无持续上升趋势。
• 资源回收：测试结束后，内存、连接数能回落到初始水平。
• 无错误：测试期间无 Deadlock found、Lock wait timeout 等错误日志。

4.5 四种测试方法对比总结