1.3 性能基线建立与趋势分析

1.3 性能基线建立与趋势分析

本节摘要：没基线没法判断"慢了"还是"本来就慢"。本节讲清楚基线建立（指标采集/归档）、趋势分析（同比环比/异常检测）、回归检测，让你能科学评估性能变化。

为什么需要基线

调优要回答"慢了"还是"本来就慢"——这需要基线对比。

• 基线：系统正常时的性能指标快照——P99、QPS、CPU、IO 等的典型值和范围。
• 对比：当前指标 vs 基线，判断是否异常。
• 趋势：长期指标变化，发现缓慢退化（如数据增长导致渐进慢）。

没基线的问题：

• 告警难定——不知道什么阈值算异常。
• 调优难评——不知道优化前后是否真改善。
• 退化难发现——渐进慢不易察觉，到事故才发现。

基线建立

1. 采集指标

• 核心指标：QPS、P50/P95/P99、CPU、内存、IO、连接数。
• 业务指标：关键查询延迟、事务成功率。
• 采集频率：秒级（实时监控）、分钟级（趋势）、小时级（长期）。

2. 采集周期

• 覆盖典型负载——工作日/周末、白天/夜间、高峰/低谷。
• 至少一个完整业务周期——如电商含大促，要含大促期。
• 多周期采样——避免单周期异常（如某天故障）。

3. 统计方法

• 不用单值——用分布（P50/P95/P99）和范围（min/max/均值）。
• 区分负载——高负载基线和低负载基线分开。
• 标注异常——剔除故障期数据，避免污染基线。

4. 归档

• 基线版本化——随系统演进更新（如架构变更后重建）。
• 存储历史——保留历史基线，对比长期趋势。
• 文档化——记录基线条件和指标，供后续参考。

趋势分析

1. 同比环比

• 同比：同期对比——如本周一 vs 上周一，排除周期性。
• 环比：相邻对比——如今天 vs 昨天，发现突变。
• 周期性数据要同比——如电商周末流量高，环比会误判。

2. 异常检测

• 阈值告警：指标超基线阈值告警——简单但易误报。
• 统计异常：指标偏离基线 N 个标准差——更智能。
• 机器学习：用算法（如 ARIMA/Prophet）预测，偏离告警——复杂但准。

3. 缓慢退化

• 渐进慢——数据增长、索引碎片、统计老化导致。
• 趋势分析发现——P99 每月涨 5%，虽慢但持续，到某点爆发。
• 提前优化——趋势恶化时优化，不等事故。

4. 容量预测

• 用趋势预测何时到瓶颈——如 QPS 月增 10%，当前 5000，瓶颈 10000，约 7 个月到。
• 提前扩容/优化——在瓶颈前行动。

回归检测

优化后要回归检测——确认没破坏其他性能：

1. 功能回归

• 优化可能破坏功能——如改索引影响查询结果。
• 回归测试——跑测试套件确认功能正常。

2. 性能回归

• 优化可能影响其他性能——如加索引提查询但拖慢写入。
• 全面监控——不只优化点，看所有关键指标。
• 对比基线——确认其他指标没退化。

3. 长期回归

• 短期好不代表长期好——如某优化短期快但长期碎片化。
• 持续监控——上线后跟踪，发现长期退化及时处理。

监控工具

1. 系统监控

• Prometheus + Grafana——通用监控，采集+可视化。
• Zabbix——传统监控，agent 采集。
• Datadog/New Relic——商业 APM，全栈监控。

2. 数据库监控

• MySQL：Performance Schema、slow query log、pt-query-digest。
• PostgreSQL：pg_stat_statements、auto_explain。
• Oracle：AWR、ASH、ADDM。
• SQL Server：DMV、Query Store。

3. APM（应用性能监控）

• 追踪应用到底层的调用链——定位慢在 DB 还是应用。
• SkyWalking/Pinpoint（开源）、Dynatrace/AppDynamics（商业）。

4. 日志分析

• ELK（Elasticsearch+Logstash+Kibana）——日志集中分析。
• 慢查询日志分析——找最慢查询。

基线和趋势的实战

场景：电商订单查询渐进慢

• 基线：3 个月前 P99 = 150ms。
• 趋势：每月涨 10ms，现在 P99 = 280ms。
• 分析：数据量从 1000 万涨到 3000 万，索引未优化。
• 预测：按趋势 2 个月到 400ms（超 SLA 300ms）。
• 行动：现在优化（加复合索引、分区），不等到超 SLA。

这是趋势分析的价值——提前发现渐进退化，主动优化。

⚠️ 常见误读：以为"基线就是平均值"。基线要用分布（P50/P95/P99）和范围，不是单值。平均值掩盖长尾，P99 才反映用户体验。

💡 关键直觉：基线是正常性能快照（分布+范围），没基线无法判断异常/退化/优化效果。建立要采集核心指标、覆盖典型负载周期、用统计分布、版本化归档。趋势分析用同比（排除周期）、环比（发现突变）、异常检测（阈值/统计/ML）、缓慢退化发现、容量预测。回归检测功能/性能/长期。工具 Prometheus/Grafana、Performance Schema/pg_stat/AWR、APM、ELK。实战：趋势分析提前发现渐进退化，主动优化。

收获清单

• 基线必要性：判断"慢了"还是"本来就慢"，没基线无法定告警阈值/评优化/发现退化。
• 基线建立：采集核心指标（QPS/P50/P95/P99/CPU/IO/连接）、覆盖典型负载周期（含大促）、统计分布（不用单值，P50/P95/P99+范围）、区分负载、剔除异常、版本化归档。
• 趋势分析：同比（同期对比排除周期性）、环比（相邻发现突变）、异常检测（阈值/统计 N 标准差/ML ARIMA-Prophet）、缓慢退化发现（渐进慢提前优化）、容量预测（趋势预测瓶颈时间）。
• 回归检测：功能回归（测试套件）、性能回归（全面监控不只优化点，对比基线）、长期回归（持续监控防短期好长期退）。
• 监控工具：系统（Prometheus+Grafana/Zabbix/Datadog）、数据库（MySQL Performance Schema/slow log/pt-query-digest、PostgreSQL pg_stat_statements/auto_explain、Oracle AWR/ASH/ADDM、SQL Server DMV/Query Store）、APM（SkyWalking/Pinpoint/Dynatrace）、日志（ELK）。
• 实战：电商订单 P99 月涨 10ms，趋势分析提前 2 个月发现将超 SLA，主动优化而非事故救火。

三种基线的对比：时点值、滑动窗口、周期对齐

建基线最容易犯的错是拿"时点值"当基线——今天下午三点抓一组指标，以后都跟它比。数据库负载有强烈的周期性（工作日/周末、白天/夜间、月初账期/月中常态），单点基线会把正常周期波动误判为异常，或者把缓慢劣化淹没在周期噪声里。滑动窗口基线（如"过去七天同时段的中位数"）好一些，能自动适应缓慢变化，但对突变（大促流量）反应迟钝。最稳健的是周期对齐基线：按"上周同一天同一小时""上月同期"对比，再叠加环比（与昨天）和同比（与上周）两个维度——同比稳定而环比突变，是事故或发布；同比缓降而环比正常，是慢性的劣化（数据增长、碎片、统计漂移）。三者的建设成本递增，建议核心库用周期对齐，边缘库用滑动窗口即可。

趋势分析里最值钱的三条曲线

第一条是缓冲池命中率的长周期曲线——它缓慢下降的斜率几乎就是"数据量增长速度 ÷ 内存大小"的直观表达，把它和外推的业务增长曲线放在一起，能直接读出"还剩几个月命中率跌破阈值"，这是最便宜的容量预警。第二条是慢查询数量按指纹分类的堆积面积图——每个查询模板一层颜色，能一眼看出新增的慢查询类型（通常是某次发布引入）和恶化的老类型（通常是数据量跨过某个阈值）。第三条是表空间增长曲线叠加碎片率——两者同涨是数据增长，空间涨而行数不涨是碎片或大事务回滚的残留，处理方式完全不同。这三条曲线的共同点是都看"斜率"而非"数值"，数值告诉你现在的状态，斜率告诉你还剩多少时间，而调优的主动性恰恰来自后者。

基线失守的三个真实场景

场景一：发布日基线污染。周二发布新版本，周三采集的基线包含了新代码的查询模式，之后两周的"异常"其实都是新常态。对策是把发布事件打点进监控系统，基线采集自动跳过发布后 24 小时。场景二：采样率陷阱。监控每分钟采一次均值，一个持续 8 秒的锁等待高峰被 7 个正常采样点稀释，趋势曲线一片祥和。对策是关键指标（锁等待、连接排队）用最大值或计数口径而非均值。场景三：幸存者偏差。重启后指标"变好"——因为最慢的那批查询还在排队中没被计入。对策是把"重启事件"本身作为基线断点记录，重启前后不做对比。三个场景的共同教训：基线不是数据集，是"数据 + 上下文"，脱离了发布记录、重启记录、大促日历的指标库，画出来的趋势线会讲三个不同的故事，而你分不清哪个是真的。

容量预测的三件武器

趋势分析的进阶是容量预测，给三件实用武器。武器一，分位数趋势而非均值趋势——容量问题首先爆发在 P99 而不是平均值上，用九十五或九十九分位的历史数据做外推，提前量才够；均值平滑掉的尖刺正是要防的东西。武器二，业务量锚定法——把资源消耗与业务指标（订单量、活跃用户、请求量）做回归，容量预测就转换成业务预测，而业务预测通常有更强的先验信息（大促日历、增长目标）；数据库团队拿着回归模型去找业务方要预测输入，比盯着监控曲线外推靠谱得多。武器三，饱和点实验——在影子环境做阶梯加压，找到"吞吐不再随负载上升"的拐点，拐点的资源水位就是这个系统的真实容量上限；纸上推算永远不如实测拐点可信。三件武器组合成完整的容量工作流：分位数趋势报警、业务锚定做季度预测、饱和点实验做年度校准——数据库不再"突然"到极限，是这套教程希望帮你达成的状态之一。

异常检测的实用主义

趋势分析配异常检测，实用主义三原则。原则一，从阈值告警起步，不急于上算法——静态阈值（利用率、队列深度、错误率）能抓住八成的异常，先把这八成做稳（阈值合理、告警去重、值班响应），再考虑智能化的边际收益。原则二，用"同环比+分位数"的组合拳对付周期性负载——按小时的同比（今天十点 vs 昨天十点）自动消除业务周期，配上分位数指标（P99 的同环比）能同时抓住"整体抬升"与"尾部恶化"两类异常。原则三，异常的定义要业务化——技术指标（缓存命中率降了两个点）是否算异常，取决于业务指标（订单创建时延）是否受损；把两层指标联动告警，能过滤大量"技术波动但业务无感"的噪音。三条原则的底层是同一个认知：异常检测的目的是让工程师的注意力投向真问题，而不是追求检测技术的精致——告警风暴比没有告警更有害，因为它教会团队忽略告警。

补一个基线档案的存放建议：把"基线快照"存成带时间戳的目录（指标导出、关键配置、慢查询清单），与变更记录同库管理——半年后复盘"为什么现在比那时慢"时，能拉出两份快照逐项对表的能力，价值远超占用的一点存储。基线是时间的切片，切片要成档案才成证据。