SQL数据库性能基线是在典型业务负载下采集的6项核心指标稳定参考值，包括平均查询延迟、QPS/TPS、活跃连接数、缓冲池命中率、磁盘I/O等待时间与IOPS、慢查询数量/分钟，用于衡量数据库健康运转的正常范围，并需随系统变更动态更新。
什么是SQL数据库性能基线
性能基线是一组在典型负载下稳定运行时采集的关键指标参考值，不是理论峰值，也不是空闲状态下的数值。它反映的是你的真实业务场景中，数据库“健康运转”的正常范围。比如：在每天上午10点订单高峰时，平均查询延迟应低于80ms，连接数维持在120–150之间，缓冲区命中率不低于98.5%——这些就是你的基线。
如何做一次有效的基准测试
基准测试不是跑一遍sysbench就完事，重点在于模拟真实行为并控制变量：
- 使用生产数据的脱敏副本，至少保留原表结构、索引、数据量级和分布特征
- 复现核心业务SQL：提取慢日志里TOP 20的查询，按调用频次加权构造测试脚本
- 分阶段施压：从50%常规并发开始，逐步增至120%，每次持续15分钟以上，跳过前2分钟预热期再采样
- 关闭非必要监控和备份任务，避免干扰；同一轮测试中不调整参数或重启服务
必须纳入基线的6项核心指标
少而精比堆砌几十个指标更有价值，以下6项覆盖响应、吞吐、资源、稳定性四个维度：
- 平均查询延迟（ms）：区分读/写，按P95统计，排除超时和失败请求
- QPS/TPS：每秒成功执行的查询数或事务数，需标注事务边界（如BEGIN…COMMIT）
- 活跃连接数：非sleep状态的连接，配合应用连接池配置判断是否合理
- 缓冲池命中率（InnoDB）或共享缓冲区命中率（PostgreSQL）：持续低于95%需排查缓存配置或热点倾斜
- 磁盘I/O等待时间（await）与IOPS：结合iostat看是否出现持续>10ms的await
- 慢查询数量/分钟：阈值设为业务可接受的上限（如>500ms），而非默认的1s
基线不是一劳永逸，需要动态维护
上线新功能、扩容节点、升级小版本后都必须重跑基准并更新基线。建议：
- 每次变更后72小时内完成对比测试，记录差异点（如加了复合索引后JOIN延迟降35%）
- 每月用历史基线回溯一次，识别缓慢漂移（例如缓冲命中率连续三周下降0.2%）
- 把基线值嵌入监控告警规则，比如“P95延迟连续5分钟 > 基线×1.8倍”触发预警
