简介面向数据库运维、开发与性能调优人员这份文档系统梳理了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、内存使用率、磁盘剩余空间、磁盘写吞吐外加一个容易漏的“磁盘增量”。指标单位建议采集频率正常区间与告警初值CPU 利用率%15-30 秒常态低于 70%持续 5 分钟高于 85% 提 P1iowait%15-30 秒低于 15% 可作初值超过时看慢查询和磁盘队列内存使用率%60 秒低于 80%重点看 Swap 是否持续增长磁盘剩余空间GB5 分钟不只看阈值要按增长速率预测剩余可用时间磁盘写吞吐MB/s60 秒看基线对比瞬时翻倍且伴随延迟上升才关注参数说明磁盘剩余空间不建议放到 30 秒的采集周期里因为使用率本身就变化慢快也没用反而是“每日增长多少 GB”这个频率要保证连续记录才能推测出磁盘什么时候会满。另一个容易忽略的是 iowait 没超阈值但磁盘已经没能力响应。这时就要结合第 2.3 节的引擎层指标把“一次全表扫描”和“iowait 飙升”放到一起看才是一份合格的文档判断。注意不同数据库的主机层命名和采集方式不完全一样MySQL 下可以直接从操作系统上取 /proc 指标Oracle 下也可以用 vmstat 落库。文档不必写死命令但要把“采集来源”这个字段留着不然后来的人换了监控工具不知道该替换哪一块。2.2 第二层数据库实例指标活跃会话、TPS、QPS、慢查询与锁等待数据库实例层是故障时最容易给出结论的一层。它描述的是“数据库这个服务当前在干什么”。大部分团队监控的是连接数、TPS、QPS这些肯定要看但不够。我重点要求加的是活跃会话和锁等待。指标说明建议采集频率用途当前连接数所有连接包含空闲连接10-30 秒看连接池是否接近上限活跃会话正在执行 SQL 的会话数10-30 秒判断数据库真实“忙不忙”的核心TPS/QPS每秒事务数和查询数30-60 秒用于趋势对比不建议做单条告警慢查询数超过 long_query_time 的 SQL 条数60 秒发现代价高的查询保留明细锁等待/并发阻塞等待锁的会话数、阻塞来源10-30 秒处理业务并发锁与数据库死锁的关键主从复制延迟从库落后主库的秒数30-60 秒读多写少业务最怕这个指标持续增长这里要解释“活跃会话”为什么比“连接数”更重要一个连接数 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 来说我通常保留四项引擎层指标说明判断参考InnoDB Buffer Pool 命中率数据页在内存中被命中的比例低于 95% 时做专项分析但要排除预热场景InnoDB redo log 状态评估 log 的写入频率和是否频繁刷盘大量更新涌入时这里会出现峰值磁盘临时表数查询产生的临时表是否落到磁盘大幅上升时优先找正在执行的大排序 SQL死锁和锁等待次数每段时间内产生锁冲突的会话数死锁不进入慢查询必须独立计数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 秒捕捉瞬间峰值需要历史连续曲线中频指标TPS、QPS、慢查询数30-60 秒能看到趋势不追求每一秒精确慢变指标磁盘剩余空间、复制延迟1-5 分钟用于趋势告警太密反而增加噪声明细记录慢 SQL 明细、死锁日志实时落库事后回看靠它重建现场参数说明采集频率不是越高越好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服务不可用、数据有风险复制中断、磁盘预测剩余不足 2 小时、死锁风暴电话加消息立即登机处理15 分钟内确认P1性能明显劣化CPU 持续高位、活跃会话超过池上限、慢查询翻倍消息通知30 分钟内响应处理完回填原因P2趋势告警磁盘增速过快、复制延迟缓慢上升消息通知当天处理不做夜间电话打扰这个表里最容易办错的是“P0 只定义症状不定义下一步动作”。我在文档模板里的每一项 P0 都会写“到哪里确认”比如“连接池满时先看活跃会话和排队中连接再看慢查询和锁等待”确保任何时候值班的人都能在十分钟内进入排障。告警不是把最响的铃声调出来就完了而是要把动作一起写进去。3.4 指标条目最小模板一个指标写一行但要有八个字段现在把采集频率、基线与告警分级合并到每一条指标里。我在文档里常用的条目如下字段示例指标名活跃会话所属层级数据库实例层采集方式从监控代理读取实例状态值采集频率15 秒告警基线活跃会话数超过连接池上限的 80%持续 5 分钟告警级别P1确认动作先看慢查询明细再看锁等待必要时抓取当前执行 SQL负责人DBA 值班组不要小看“采集方式”和“确认动作”这两列。采集方式写清楚之后换监控平台时不至于重新猜一遍数据来源确认动作则把文档从“指标字典”变成了“值班手册”。新接手的人照着模板读一遍能形成基本的排障路径。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. 做一次主动故障演练检验监测指标文档是不是白纸一张指标文档在纸面上再正确也可能在采集链路或阈值细节上留洞。所以我的习惯是写完文档后做一次主动演练而不是等下一个故障来了再验证。具体做法是挑一个低谷时段选一台非核心业务的从库或测试库把文档里的指标当作检查项逐个实践一遍。步骤选一台测试库挑出文档中“最容易配置错”的三项指标比如活跃会话、锁等待、主从延迟。人工构造一个 30 秒的锁等待场景在测试库中开启一个事务并更新某一行持有行锁不提交再开启另一个会话去更新同一行。此时第二个会话处于等待状态。等 5 分钟看监控是否按文档中的阈值触发对应告警以及通知是否到达正确人员。操作一次恢复保留演练结果记录在文档的验证栏里。演练项通过标准未通过时的原因方向锁等待监控10-30 秒内观察到会话数上升并按 P1 通知采集周期太长、字段没配对、通知名单为空活跃会话监控超过阈值产生告警阈值基线未生成监控平台配置与文档不一致主从延迟监控人为暂停从库复制 60 秒后产生 P1主从复制的状态采集源没配置磁盘增量预测写入临时大文件后剩余可用时间低于 24 小时触发增长速率口径不对只有总量没有增量演练之后还要做月度复评。每月底把过去 30 天每个指标的触发次数和误报次数拉出来误报率高的阈值调高漏报的指标补采集。我在银行系维护数据库时还保留一个习惯每次线上故障处置完就要把当时一串异常指标和处置顺序标到对应指标的备注里让这份文档在这些案例的基础上变成团队自己的手册。后面你再去看新同事处理故障会明显感觉到他不再盯着监控页面发愣而是照着文档一层层往下走。这个习惯比任何一次培训都管用。希望帮到你。本文还有配套的精品资源点击获取