企业官网建设流程全解析

简介：面向数据库运维、开发与性能调优人员，这份文档系统梳理了Oracle、SQL Server、Sybase、Informix、DB2等主流数据库的监测指标体系。内容覆盖游标数、Session数、每秒事务数、锁与死锁、缓冲池命中率、缓存命中率、表空间使用率、日志写入速率等关键监测项，并结合每类指标说明其反映的瓶颈与调优方向，便于建立巡检清单或监控模板。

资源包为单个DOC文档，共1个文件，大小286KB，结构按数据库类型分节，并细分为性能、表空间、连接数、内存管理等模块，可直接打印或按需检索。文档还包含Listener状态、Largest Chunk、Page Read/Write Rate等进阶指标，适合从入门到进阶的DBA查阅。

该文档已有83人学习，适用于需要快速掌握数据库监控重点、排查性能隐患的读者，也可作为日常运维中的参考手册，帮助合理配置资源、预防瓶颈。

1. 数据库监测指标到底要管什么：先定框架再定清单

晚上十点，一个核心订单库突发变慢。你打开监控看板，连接数、TPS、缓存命中率全是绿色，只有 CPU 是 92%。排查半小时后才发现，连接池早就满了，新的连接在排队等待中越积越多，而你的监测指标里根本没有“排队中的连接数”这一项。这类事故在 MySQL、Oracle、PostgreSQL 环境下都反复上演，根子往往不在监控工具的图形好不好看，而在你手上的那份《数据库监测指标》清单本身。它不是一张截图，而是一份规定每个指标“怎么采、多久采一次、正常范围在哪里、触发哪一级告警”的规格说明。下面这套做法适合正在编写或重新整理数据库监控指标清单的 DBA、SRE，以及常被数据库拖去救火的研发负责人。先把三层指标拆开，你会发现在写文档之前，先做指标分类比打开监控工具更重要。

2. 把监测指标拆成三层：从主机到实例再到数据库内部的 20 项必选指标

写指标文档最容易犯的错，是从一张“监控工具支持什么”的列表往下抄：连接数、TPS、慢查询、磁盘……抄完 50 项，觉得挺全，真正出了事还是不知道从哪看起。我的做法是把指标按现象来源拆成三层：主机与操作系统层、数据库实例层、数据库内部引擎层。每一层回答的问题是递进的：服务器资源够不够用、实例还在不在正常处理请求、引擎内部有没有在偷偷做低效动作。后面值班的人拿到这份文档，按从下到上的顺序逐层去看，而不是在几十项指标里瞎猜。

2.1 第一层：主机与操作系统指标，CPU、内存、iowait 和磁盘增量

先看主机层，因为数据库跑在操作系统上面，很多“库里慢”的现象，根因在磁盘或内存。举例来说，一条 SQL 平时 20 ms 跑完，今天变成 300 ms，你从数据库实例层只能看到“慢查询变多”，但看不到磁盘 IO 等待时间翻了五倍。所以我在文档第一层固定放五到六项：CPU 利用率、iowait、内存使用率、磁盘剩余空间、磁盘写吞吐，外加一个容易漏的“磁盘增量”。

参数说明：磁盘剩余空间不建议放到 30 秒的采集周期里，因为使用率本身就变化慢，快也没用；反而是“每日增长多少 GB”这个频率要保证连续记录，才能推测出磁盘什么时候会满。另一个容易忽略的是 iowait 没超阈值，但磁盘已经没能力响应。这时就要结合第 2.3 节的引擎层指标，把“一次全表扫描”和“iowait 飙升”放到一起看，才是一份合格的文档判断。

注意：不同数据库的主机层命名和采集方式不完全一样，MySQL 下可以直接从操作系统上取 /proc 指标，Oracle 下也可以用 vmstat 落库。文档不必写死命令，但要把“采集来源”这个字段留着，不然后来的人换了监控工具不知道该替换哪一块。

2.2 第二层：数据库实例指标，活跃会话、TPS、QPS、慢查询与锁等待

数据库实例层是故障时最容易给出结论的一层。它描述的是“数据库这个服务当前在干什么”。大部分团队监控的是连接数、TPS、QPS，这些肯定要看，但不够。我重点要求加的是活跃会话和锁等待。

这里要解释“活跃会话”为什么比“连接数”更重要：一个连接数 256 的实例可能只有 10 个会话正在干活，另一个只有 20 个连接却有 15 个在跑大 SQL。数据库不是连接数多才变慢，而是活跃会话把 CPU、IO 和锁资源吃掉了。所以我在文档里不会写“连接数 > 80% 就告警”，而是写“活跃会话占连接池上限超过 80%，且持续 5 分钟，提 P1”。连接数本身是一条看板指标，而不是核心告警指标。

这一层还要说清指标之间的因果顺序。慢查询数变多之后，活跃会话会跟着上涨；活跃会话过多之后，CPU 或 iowait 才被顶起来。文档在“关联影响”里标注这种顺序，可以把排查时间从半小时压缩到五分钟。

2.3 第三层：数据库内部引擎指标，缓存命中率、redo 日志与死锁

到了第三层，才是数据库真正区别于“一台装了数据库的服务器”的地方。这一层每个数据库都有差异：MySQL 要看 InnoDB 状态，Oracle 要看等待事件和 SGA 命中率，PostgreSQL 要看 shared_buffers 命中率和 WAL 写入。不要试图写一张所有数据库通用的表，不同引擎关键指标完全不同，硬通用等于没有重点。

对 MySQL 来说，我通常保留四项：

Oracle 的写法不一样。Oracle 里我常列“库缓存命中率、redo 日志切换频率、Top 等待事件”，把 v$session 作为比活跃会话更细的一层。文档里可以做一张对照说明，写清楚“本环境是 MySQL 再看 InnoDB 段，是 Oracle 再看等待事件段”。如果你在信创环境里落到达梦数据库或人大金仓，指标命名可能略有差异，但三层结构是同一套，照着目标库的官方系统表映射一遍即可。

2.4 总量控制在 20 项，为什么不是越多越好

把三层都列完，常见的指标数量会到 50 项以上，问题也来了：监控大盘一屏放不下，值班的人慢慢就不看了。我在文档中给团队定了个规矩，基础版只保留 20 项主指标，每项对应一个负责人；多出来的指标作为补充指标，只在专项分析时打开。

取舍标准很简单：这个指标异常时，你是否能立刻说出下一步动作？答不上来的就不写进主监控。比如“缓存命中率”这一类，单个值 100% 和 90% 并不能直接对应故障，但它能解释“为什么慢查询突然变长”，所以可以作为间接指标保留，不设告警，只看趋势。数量一旦降下来，后端的图形工具、告警规则、值班手册都可以围绕同一个指标清单搭，不会出现文档和监控工具各说各话的情况。

3. 让指标文档可执行：采集频率、三档基线与告警分级怎么写

指标清单写出来只是第一步，难点在把每个指标配成一段“可执行规则”。如果只写“连接数过高告警”，新来的同事不知道多少算高、多久没降算持续、告警后该通知谁。我在实际项目中的做法是先统一采集频率，再定三档基线，最后把告警分成三级，再与指标条目模板合并，形成能直接抄进值班手册的格式。

3.1 采集频率：快变指标 10-30 秒，慢变指标 1-5 分钟，不能一刀切

很多团队为了省事，所有指标统一 30 秒采集一次。这样做的坏处不是数据不准，而是把采集压力浪费在不重要的指标上，快变指标的窗口又太长。活跃会话 30 秒采一次，正好错过 5 秒内的一次锁等待峰值，告警自然发不出来。

参数说明：采集频率不是越高越好，10 秒以下对监控端压力大，普通业务数据库并没有那么高的实时要求。另外，文档里最好把“保留周期”一并写上：聚合数据保留至少一年，明细数据保留 30 到 90 天。很多团队调好频率却忘记保留策略，故障排查时明细早已被覆盖，只能干瞪眼。

3.2 阈值三档：静态初值、动态基线与业务高峰基线

阈值是最容易“今天拍脑袋，明天处处误报”的地方。我一般分三档来做：静态初值、动态基线和业务高峰基线。

第一档是静态初值。新数据库刚接入时没有历史数据，可以先按常用经验值填表，比如连接数按连接池上限的 70%、iowait 用 15%、磁盘剩余可用时间用 24 小时。这些值先运行一周，目标不是准确，而是让监控系统先有“锚”。

第二档是动态基线。运行 7 天后，拿每日 P95 和 P99 作为基线。动态基线比静态初值更贴近真实业务，我会把告警阈值设为“当前值超过基线的 1.5 倍”或者“超过 P99 再持续 N 分钟”。比如 QPS 平时 1000，某天涨到 3000 不代表故障，可能只是促销活动；按基线看，涨到 7000 且持续 5 分钟才触发告警，误报会大幅下降。

第三档是业务高峰基线。电商大促、月度结账、财报季这类短时高峰，不是故障却会冲高所有指标。文档里要为这种窗口单独写一组“活动基线”，注明起止时间、调高后的阈值、恢复时间。这一档最容易被忽略，后面第 4 章的坑 4 会专门讲。

3.3 告警分级：P0、P1、P2 各带确认动作，不是只响一声

告警分级的价值在于让不同级别事件进入不同处理通道。我推荐的写法如下：

这个表里最容易办错的是“P0 只定义症状，不定义下一步动作”。我在文档模板里的每一项 P0 都会写“到哪里确认”，比如“连接池满时先看活跃会话和排队中连接，再看慢查询和锁等待”，确保任何时候值班的人都能在十分钟内进入排障。告警不是把最响的铃声调出来就完了，而是要把动作一起写进去。

3.4 指标条目最小模板：一个指标写一行，但要有八个字段

现在把采集频率、基线与告警分级合并到每一条指标里。我在文档里常用的条目如下：

不要小看“采集方式”和“确认动作”这两列。采集方式写清楚之后，换监控平台时不至于重新猜一遍数据来源；确认动作则把文档从“指标字典”变成了“值班手册”。新接手的人照着模板读一遍，能形成基本的排障路径。

4. 数据库监测指标落地避坑与常见问题：5 个真实踩坑案例

前几章是按“正确写法”来推的。实际上线时，指标文档往往会在阈值、频率和监控对象上出现各种偏差。下面这 5 条是我这几年在 MySQL、Oracle 和 PostgreSQL 环境里都亲测见到的坑，按现象、原因、解决的顺序记录。

4.1 坑 1：连接数告警等到 80% 才触发，业务其实早挂在排队上了

现象：监控面板显示“当前连接数 152/200”，按 80% 阈值触发 P1 告警，但业务接口超时率已经到 12%。你以为是告警晚了，实际上不是晚，而是等了太久。

原因：连接池是“用完了就排队”的结构。当连接数到 80% 时，剩下的 20 个空闲槽位并不代表还能继续接收新请求，因为新请求早已开始排队；排队时间变长，上游超时重试，又继续把队列堆满，最后在连接数真正到 100% 之前就已经雪崩。

解决：不要只监控总连接数，把“排队中连接数”或“活跃会话数”和总连接数一起放进文档。以 MySQL 业务为例，活跃会话数达到连接池上限的 70% 时提前告警；总连接数那条阈值只作为兜底，而不是主告警。

4.2 坑 2：磁盘使用率 85% 就告警，却没算“多久会写满”

现象：磁盘使用率 85% 触发 P2，值班人员看了一眼，确认还没满，就没处理。第二天中午，磁盘直接满了，数据库写入失败，业务中断。

原因：使用率是一个快照，而 binlog、undo、临时文件、系统日志都是高速增长的变量。只看快照不看增长速率，等于看到“水位 85%”却没估算“每小时涨 3%，剩 18 小时”。等 85% 告警开始响，留给处置的时间可能已经不足半天。

解决：文档里把“磁盘剩余空间”改成“磁盘剩余可用时间”：剩余容量除以最近 6 小时的日平均消耗速率。当预估值低于 24 小时，直接给 P0。这一步在 MySQL、Oracle、达梦等各类数据库和普通服务器上通用，操作系统层收集即可。

4.3 坑 3：慢查询用 60 秒聚合，把瞬间锁等待直接抹平了

现象：慢查询指标显示“0 条”，但业务日志里出现多次秒级卡顿，排查下来是行锁等待和少量死锁，并不是 SQL 本身执行慢。

原因：慢查询只统计执行时间超过 long_query_time 的语句，单纯等待锁并不算慢，而 60 秒维度的聚合又把瞬时值平均掉了。我看过最典型的一次，是批量更新高峰期每分钟锁等待 20 次，聚合后每分钟平均变成“0.3 次”，等于直接隐身。

解决：把锁等待、数据库死锁作为独立指标，采集频率缩短到 10-30 秒，并且保留死锁日志。MySQL 下可以用SHOW ENGINE INNODB STATUS看到最近一次死锁信息，但要拿到全量死锁趋势还是得靠监控平台单独采集。慢查询那条维持 60 秒做趋势即可，不能拿它替代锁监控。

4.4 坑 4：大促前调高阈值，活动结束忘了恢复，基线被污染

现象：大促当天值班同事把连接数阈值从 80% 调到 95%，活动结束没有恢复。之后一个月，系统在连接数 90% 左右运行也不告警，直到一次新的活动出现误报风暴。

原因：活动期间的高负载被当成“正常业务”，动态基线也随之抬高。如果文档里没有临时调整的登记，回忆时找不到是哪位同事调的，也不知道该在什么时候恢复。

解决：在指标条目模板中加两个字段：临时调整起止时间和恢复负责人。活动结束当天做一次阈值回归检查，把动态基线重新计算。上线到文档里的所有指标，都要能回答“这个阈值什么时候被改过、为什么改”。

4.5 坑 5：主库指标很全，从库只有复制延迟，读流量把从库打垮了

现象：主库 CPU 不到 50%，所有指标正常，从库查询超时严重。值班同事查监控发现“从库根本没有连接数、活跃会话这些指标”，只有一行主机 CPU 和一个复制延迟。

原因：监控文档把“从库”当成主库的附属，只加了一个主从复制延迟指标。但绝大多数读流量是打在从库上的，从库的 CPU、内存、磁盘和连接池状态与主库处于完全不同的水位。

解决：文档要对主库和从库分别建条目，不能共用一行“连接数”。从库至少包含活跃会话、复制延迟、磁盘增量三项，复制延迟阈值要按业务读多写少的容忍度设置，比如 5 秒或 10 秒就要告警，而不是默认 60 秒以上。这样才能在从库被读流量拖垮前收到信号。

5. 做一次主动故障演练，检验监测指标文档是不是白纸一张

指标文档在纸面上再正确，也可能在采集链路或阈值细节上留洞。所以我的习惯是写完文档后做一次主动演练，而不是等下一个故障来了再验证。具体做法是挑一个低谷时段，选一台非核心业务的从库或测试库，把文档里的指标当作检查项，逐个实践一遍。

步骤：

1. 选一台测试库，挑出文档中“最容易配置错”的三项指标，比如活跃会话、锁等待、主从延迟。
2. 人工构造一个 30 秒的锁等待场景：在测试库中开启一个事务并更新某一行，持有行锁不提交；再开启另一个会话去更新同一行。此时第二个会话处于等待状态。
3. 等 5 分钟，看监控是否按文档中的阈值触发对应告警，以及通知是否到达正确人员。
4. 操作一次恢复，保留演练结果记录在文档的验证栏里。

演练之后还要做月度复评。每月底把过去 30 天每个指标的触发次数和误报次数拉出来，误报率高的阈值调高，漏报的指标补采集。我在银行系维护数据库时还保留一个习惯：每次线上故障处置完，就要把当时一串异常指标和处置顺序标到对应指标的备注里，让这份文档在这些案例的基础上变成团队自己的手册。后面你再去看新同事处理故障，会明显感觉到他不再盯着监控页面发愣，而是照着文档一层层往下走。这个习惯比任何一次培训都管用。希望帮到你。

本文还有配套的精品资源，点击获取