数据库可观测性与性能监控

• 成本可观测性定义
• 成本度量维度
• 成本归因与优化

成本可观测性（Cost Observability）指能够量化、追踪并归因数据库的各类成本，而不仅是性能指标。它涵盖：资源成本（CPU、内存、磁盘、IOPS、网络）、查询成本（每条 SQL 的耗时、资源消耗、扫描量）、存储成本（数据量、增长、压缩）、以及人力/运维成本。通过把成本与业务维度（应用、租户、功能、表）关联，可回答"哪个查询/业务最贵、钱花在哪"。典型工具如云数据库的成本分析、性能洞察的成本归因、查询的 I/O 与执行成本打点。它驱动成本优化（删冗余查询、归档冷数据、缩容、调参）。

传统可观测性关注"性能与可用性"，成本可观测性补充"钱花在哪"。在云上按需计费、成本敏感的场景尤其重要，把成本与负载颗粒绑定，才能精准优化与止损。

• slow query log 采集
• SQL 指纹归一化
• 执行计划对比与根因定位

标准慢查询排查流程：1) 采集：开启 slow query log（MySQL slow_query_log）或 pg_stat_statements 记录慢 SQL；2) 归一化：用 pt-query-digest 或 pg_stat_statements 把 SQL 指纹化（把字面量替换为占位符，聚合相同模板），得到各模板的累计次数、平均/最大耗时、总耗时占比，定位 TOP 慢 SQL；3) 执行计划对比：对关键慢 SQL 用 EXPLAIN/EXPLAIN ANALYZE 查看执行计划，对比"实际 vs 预估行数"偏差、是否走索引、join 顺序，可与优化前后计划对比；4) 根因定位：结合索引缺失（seq scan）、统计过期（行数偏差大导致选错计划）、锁等待（锁冲突）、参数设置等确定根因，再针对性优化。

全链路的关键是"归一化聚合 + 计划对比归因"。指纹归一化把海量慢日志压缩成可排序的模板，计划对比暴露"为什么慢"，根因定位把现象（慢）落到具体原因（索引/统计/锁），形成可执行优化闭环。

• 连接池关键指标
• HikariCP leakDetectionThreshold
• PgBouncer stats 与连接池配合

连接池监控指标包括：活跃连接数（当前在用的连接数）、最大连接数占用率、等待队列长度（连接被占满后的等待请求数）、连接获取延迟（从池中获取连接的时间，关注 p99）、连接泄漏（borrow 后长时间未归还）。HikariCP 的 leakDetectionThreshold 设置一个阈值，超过该时长未归还的连接被判定为泄漏并记录告警，用于发现"借而不还"的代码缺陷。PgBouncer 是独立的连接池/代理，SHOW STATS 提供总连接、活跃请求、等待客户端等统计。二者配合：应用侧 HikariCP 负责应用内连接复用与泄漏检测，数据库侧 PgBouncer 承接大量客户端连接并复用后端连接，监控需同时看应用侧获取延迟与池占用、代理侧连接数与等待，形成"应用池 + 代理池"两层观测。

连接池是事务吞吐的咽喉。监控要看"会不会拿不到连接"（等待队列、获取延迟）与"连接是否被泄漏"（归还超时）。HikariCP 管应用内，PgBouncer 管数据库入口，两层配合既能防泄漏又能缓解连接风暴。

• RED 方法（Rate/Errors/Duration）
• USE 方法（Utilization/Saturation/Errors）
• 告警体系构建

RED 方法面向"服务/请求"维度：Rate（请求速率，如 QPS）、Errors（失败率，HTTP 错误/SQL 错误比例）、Duration（延迟分布，p50/p95/p99）。USE 方法面向"资源"维度：Utilization（资源利用率，CPU/IO/内存）、Saturation（饱和度，队列深度、等待项）、Errors（资源错误）。二者组合覆盖"请求体验 + 资源负载"两层：RED 回答"服务是否健康、是否变慢、是否报错"，USE 回答"哪个资源被打满、是否饱和"。告警体系据此分层：QPS 突降/突增、错误率超阈值、p99 超 SLO、CPU/IO 利用率高、队列深度超阈值等都作为告警项，并设置分级（警告/严重）与抑制。

RED 从用户视角看服务健康，USE 从资源视角看瓶颈，互补。完整告警体系 = 请求层（RED）+ 资源层（USE）+ 分级与抑制，避免"只盯 CPU 却漏掉变慢"或"只盯延迟却不知资源为何饱和"。

• pg_stat_statements SQL 统计
• pg_stat_activity 实时会话
• pg_stat_replication / pg_stat_bgwriter / auto_explain

PostgreSQL 提供丰富的可观测性视图：pg_stat_statements 记录聚合后的 SQL 统计（调用次数、总/平均耗时、块读写、IO 时间），用于定位 TOP SQL；pg_stat_activity 显示实时会话（状态、当前查询、等待事件、锁），用于查看阻塞与长事务；pg_stat_replication 提供复制延迟（主备的 sent/write/flush/replay 位置与 lag），用于监控备库落盘与复制健康；pg_stat_bgwriter 反映 checkpoint 与 buffer 写入（checkpoint 次数、统计、缓冲写），用于评估 checkpoint 与写入压力；auto_explain 扩展自动记录超过阈值的查询执行计划，便于复盘慢查询。这些视图共同构成 PG 的观测链路。

各视图分工：statements 看"哪些 SQL 慢/多"，activity 看"当前在干什么/卡在哪"，replication 看"复制是否追得上"，bgwriter 看"checkpoint 是否成为瓶颈"，auto_explain 看"慢查询的计划"。组合使用才能完整诊断。

• Performance Schema 事件表
• events_statements_summary_by_digest
• events_waits_summary_global_by_event_name

MySQL 的 Performance Schema 提供细粒度执行事件统计。events_statements_summary_by_digest 按 SQL 指纹（digest）聚合语句：累计执行次数、总/平均耗时、锁等待、扫描行数、临时表等，可排序找出 TOP SQL（耗时最长/最频繁）。events_waits_summary_global_by_event_name 按等待事件名聚合等待（如 IO、锁、mutex、日志刷盘），可定位系统瓶颈在哪个资源（磁盘 IO、锁等待、网络等）。sys schema 是对 Performance Schema 的友好封装，提供格式化视图（如 sys.statement_performance_analyzer、sys.io_global_by_wait_by_bytes），降低查询门槛。二者配合实现"先找 TOP SQL，再找瓶颈资源"。

从"语句"和"等待"两个维度切入：语句维度定位慢/重 SQL，等待维度定位瓶颈资源。sys schema 让分析更易用，两者结合是 MySQL 性能排障的标准路径。

• 采集频率与开销
• Performance Schema 采样
• 慢日志开关权衡

监控采集本身有开销，需权衡精度与性能：Performance Schema 全量开启会显著增加内存与 CPU 开销（尤其是高并发下统计每个事件），生产上需配置采样（如只统计部分会话、按 digest 聚合、关闭不必要的事件消费者）或降低采集频率；慢查询日志（slow_query_log）记录每个慢 SQL 涉及磁盘 IO 与日志轮转，若阈值设得太低或记录全量，会放大写入并拖慢性能。因此生产监控设计要"按需采集"：高精度指标采样而非全量，慢日志只记录超过阈值的 SQL，监控抓取频率与指标粒度匹配，避免"监控拖垮业务"。

采集是"观测的代价"。样本过多导致性能与存储成本上升，样本过少失去诊断价值。正确做法是分级采集（关键指标高频、明细事件低频/采样）、关闭冷门消费者、控制慢日志范围，让监控开销可控。

• 业务可观测性定义
• 业务指标（延迟、吞吐、成功率）
• 与技术指标的关系

业务可观测性（Business Observability）指从业务/用户视角观测数据库，把技术指标映射为业务结果。它关注业务级指标：交易成功率、订单量、响应时间（用户感知）、业务吞吐、单位业务成本、业务高峰/低谷规律，以及"业务影响"（如某 SQL 变慢导致支付成功率下降）。与技术指标（CPU、QPS、锁等待）相比，业务可观测性回答"业务是否健康、用户是否受影响"，而非"系统资源如何"。它把数据库指标与业务 KPI 关联，用于 SLA 达成监控、容量规划与变更影响评估。

技术指标是"手段"，业务指标是"目的"。业务可观测性把技术指标翻译成业务语言（如"转账成功率"而非"锁等待 ms"），让非技术方也能理解系统健康，并指导优先级（优先保障影响业务的环节）。

• 延迟基线（p50/p95/p99）
• 同比/环比异常检测
• 计划回归（plan regression）检测

建立 SQL 延迟基线：对每条 SQL 模板持续采集延迟分布，计算 p50/p95/p99 作为阈值基线，并随时间滚动更新（如按天/周聚合）。异常检测用同比/环比：环比（与上一时段比）反映即时波动，同比（与上周同期/基线比）反映慢趋势，超过设定的倍数或阈值即告警。计划回归（plan regression）指优化器因统计变化、参数、数据分布而选了更差的执行计划，导致同一 SQL 变慢。检测方法：对比同一 SQL 的执行计划变化（plan hash、EXPLAIN 结构）、对比相似负载下的耗时跳变、用预测/基线偏离检测；一旦发现计划回归，可固定计划（hint/plan guide）、ANALYZE 更新统计、或回退优化设置。

基线是"正常的样子"，异常检测是在基线之上找偏差。同比/环比组合能区分瞬时噪声与系统性退化；计划回归是"性能突然变差"的常见根因，需通过"计划对比 + 基线偏离"捕获并干预。

• trace_id 透传（SQL comment hint）
• 跨服务/跨分片归因
• SQL Digest/Audit 与 OpenTelemetry

全链路追踪把应用侧的 trace_id 透传到数据库层，常见手段是"SQL comment hint"：在 SQL 前缀注入 /*trace_id=...*/ 注释，数据库解析并记录该 trace_id，使 DBA 能按 trace_id 关联到具体请求与 SQL。这样可把应用的链路（服务 A→B→DB）与数据库内部执行（跨分片、多节点）关联，实现跨服务 + 跨分片查询耗时归因。TiDB 的 SQL Digest 对 SQL 做指纹归一化，配合执行信息与资源组输出到 OpenTelemetry（span 记录 SQL 模板与耗时）；OceanBase 的 SQL Audit 记录每条 SQL 的执行审计（耗时、等待、plan），可导出到 OpenTelemetry（SQL 作为 span，含 trace_id 关联）。对接后，指标/日志/追踪统一到 OTel 体系，实现端到端归因。

关键是把"应用层标识"与"数据库层执行"打通。trace_id 透传（comment hint）让数据库日志能回连到调用链；SQL Digest/Audit 提供数据库侧结构化数据，通过 OpenTelemetry 标准 span/exporter 接入统一观测平台，精准归因跨节点慢查询。

• 资源饱和度指标
• Buffer Pool 命中率 / WAL / 临时文件 / 锁等待
• 分级响应

资源饱和度预警覆盖多个维度：Buffer Pool 命中率（<99% 往往意味着内存不足、大量磁盘读，需告警）、WAL 写入延迟（日志刷盘慢，反映磁盘 IO 瓶颈或同步模式问题）、临时文件使用量（排序/join 落盘过多，反映内存不足或大查询）、锁等待时间（锁等待超阈值，反映并发冲突或死锁）。分级响应策略：按严重程度分级：预警（Yellow）关注趋势、收集信息；警告（Orange）触发告警、DBA 介入；严重（Red）影响可用性、立即止损/扩容。响应动作包括扩容内存、优化查询减少落盘、调整同步模式、排查锁与长事务、限流或终止大查询。

饱和度指标是"资源将要用尽"的前兆，提前告警可避免性能雪崩。分级响应让告警从"都响"变成"分轻重"，集中人力处理最严重问题，并配套可执行的缓解动作。

• Performance Insights / DAS 原理
• 等待事件时间切片
• 瓶颈类型区分

AWS Performance Insights 与阿里云 DAS 的原理相似：持续采集数据库的等待事件（wait event）与负载会话，按时间片（如秒/分钟）聚合，把"总负载（DB Load）"按等待事件类型堆叠可视化为面积图/柱状图。DB Load 以"活跃会话数"为单位，展示每一时刻哪些等待事件占用最多。通过堆叠图，可快速区分瓶颈类型：IO bound（大量等待在 IO 类事件，如日志刷盘、数据文件 IO）、CPU bound（大量等待在 CPU，会话处于 running/CPU 消耗）、Lock bound（等待在锁类事件，如锁等待、行锁、元数据锁）。配合 SQL 关联（哪些 SQL 贡献这些等待），可定位根因。

"以等待事件为维度的负载堆叠"是核心：把 DB Load 拆解成等待事件，一眼看出瓶颈类别。时间切片让趋势可见，按等待类型归类（IO/CPU/Lock）直接指导优化方向（加内存/换 IO、加 CPU、查锁）。

• 监控大盘核心指标
• 告警阈值设计
• 容量预警

数据库监控大盘通常分几层：性能层（CPU、内存、磁盘 IO、网络）、数据库层（QPS、连接数、慢查询、锁等待、事务/复制延迟、Buffer 命中率、临时文件）、存储层（空间使用、增长趋势、备份状态）、业务层（错误率、p99 延迟）。告警阈值按指标设定并分级：如连接数 > 80% 上限、CPU > 85%、慢查询数突增、复制延迟 > 阈值、Buffer 命中率 < 99%、磁盘空间 > 85% 预警 > 95% 严重。容量预警基于趋势预测：磁盘/存储增长外推、连接/QPS 峰值预测达到容量上限的时间，提前规划扩容或归档。大盘需"一屏看清健康度 + 关键指标趋势 + 告警状态"。

大盘的价值是"全局可读 + 阈值可执行 + 趋势可预测"。核心指标覆盖从资源到业务，阈值分级避免告警噪音，容量预警基于增长趋势做前瞻性规划，避免"用到爆才发现"。

• MySQL 等待事件
• PostgreSQL 等待事件
• 瓶颈识别

MySQL 通过 Performance Schema 的等待事件分类（如 IDLE、IO、LOCK、MUTEX 等）与 sys 视图，等待类型包括 IO（InnoDB 数据文件、redo log 刷盘）、锁（表锁、行锁、元数据锁）、线程（调度）、misC 等，可识别 IO bound（IO 等待高）、锁 bound（锁等待高）、CPU bound（大查询占 CPU）。PostgreSQL 通过 pg_stat_activity 的 wait_event_type/wait_event 分类（如 IO、Lock、LWLock、Client、Activity、Buffer），等待类型包括：IO（datafile、wal、buffer）、Lock（relation、tuple、transactionid）、LWLock（buffer_content、buffer_mapping）、Client（client read/write）、Activity 等，可识别 IO 瓶颈、锁冲突、系统等待。两者都通过"等待事件占比"定位瓶颈资源。

等待事件体系是"数据库自己告诉你卡在哪"的机制。MySQL 侧重 InnoDB 存储层等待，PostgreSQL 侧重进程/锁/IO 等待，分类后用"哪类等待占比高"判断瓶颈类型，再结合具体 SQL 归因。

• SLI/SLO 定义
• 错误预算（error budget）
• 容量规划驱动

SLI 是可测量的指标（如可用性=成功请求比例、延迟 p99、吞吐 QPS），SLO 是 SLI 的目标（如可用性 99.99%、p99<10ms、吞吐>50K QPS）。错误预算是"未达到 SLO 的允许额度"：如 99.99% 可用性意味着每月允许约 4.3 分钟故障，这 4.3 分钟就是错误预算。当错误预算消耗过快（接近花完），说明系统接近违约，需暂停有风险的发版、优先优化与扩容；当预算充足，可进行优化性变更。容量规划据此：若吞吐/延迟逼近 SLO 且预算消耗加速，则提前扩容（实例、连接、存储），避免在预算耗尽时才响应。SLO 驱动"该不该动、何时动"。

SLO 让"服务是否达标"可量化，错误预算把"可靠性"变成可消耗的资源，指导变更时机与容量规划。它把可靠性从"玄学"变成"可管理的预算"，避免"过度追求 100%"或"频繁破坏可用性"。

• 慢查询闭环
• 抓取→计划→索引→容量
• 持续优化

慢查询优化闭环：1) 抓取：通过慢日志/统计抓取慢 SQL 并归一化排序；2) 执行计划：用 EXPLAIN 分析执行计划，看是否走索引、行数偏差、join 顺序、非必要扫描；3) 优化：优先补索引（覆盖索引、复合索引、避免回表）、改写 SQL（避免函数套列、减少多余扫描）、调整统计（ANALYZE）；4) 容量：若优化后仍因资源不足（CPU/IO/内存）而慢，则扩容或降低负载；5) 回归验证：优化后对比耗时与计划，确认提升，并持续监控防止回退。形成"抓取→诊断→优化→容量→验证"的闭环。

闭环强调"从发现到解决再到验证"而非单点处理。先看计划（索引/写法），再上容量（资源），顺序是"先优化再扩容"，避免盲目加资源掩盖问题；回归验证确保闭环有效。

• 慢查询与锁等待关联
• 锁等待导致慢
• 阻塞链分析

慢查询与锁等待常互为因果：某个 SQL 变慢可能不是自身计划差，而是被其他事务的锁阻塞（等待锁释放）。关联分析思路：1) 看慢查询的等待事件/等待时间，若含锁等待（如 MySQL 的 lock 等待、PG 的 Lock 等待）则提示锁问题；2) 用 session 视图（pg_stat_activity / information_schema 锁表）找当前阻塞链：谁持有锁、谁在等待（blocking/blocked），定位源头事务；3) 结合慢查询日志时间与锁持有时间，判断是"长事务持锁"导致后续 SQL 排队，还是"锁争用"导致本身慢；4) 分析死锁日志与锁等待超时。缓解：优化长事务、缩短持锁时间、降低并发争用、调整隔离级别。

"慢"未必是"查询自身慢"，可能是"等锁慢"。关联分析把"慢查询现象"与"锁等待根因"连接，通过阻塞链定位持锁源头，再通过缩短事务/减少争用解决，避免误判为计划问题。

• 巡检清单项
• 周期检查
• 健康度评估

数据库巡检是周期性（日/周/月）的健康检查，核心清单包括：连接数（当前连接、峰值、是否接近上限、是否有泄漏）、慢查询（近周期慢 SQL 数量与 TOP、是否有新慢查询）、锁等待（锁等待次数与时长、是否存在阻塞链/死锁）、复制延迟（主备延迟、复制是否正常、有无断流）、备份成功率（备份是否按时完成、成功与否、能否恢复=PITR 测试）、以及空间/容量、日志错误、资源利用率等。巡检输出健康度报告，发现问题（如备份失败、复制延迟、连接耗竭）立即处理，形成周期性"排查-发现-修复"机制。

巡检是"预防性运维"，在故障发生前发现隐患。清单覆盖可用性（连接/复制/备份）、性能（慢查询/锁）、容量（空间）等关键维度，周期检查保证覆盖与及时性，避免"平时不查、出问题才救火"。