简介一份面向数据库管理员与运维人员的《数据库巡检方案》Word文档系统梳理Oracle数据库日常健康巡检的关键环节包括实例与后台进程状态、文件系统空间、运行日志与监听日志清理以及性能监控、备份恢复、权限安全和参数调整等注意事项可作为日常巡检的清单式参考。资源为单个docx文件约2MB便于下载后直接查阅或打印执行。内容结合常用命令示例如查看SID、使用df/bdf检查磁盘空间、定位alert日志、通过RMAN确认备份结果并给出保留最近错误信息、设置滚动机制等日志清理原则。读者可据此快速形成规范巡检流程预防空间不足或日志膨胀引发故障提升数据库稳定性与运维效率。目前已有136人学习适合数据库运维人员作为日常操作模板。1. 数据库巡检方案先明白它到底在防什么数据库巡检最大的价值不是发现故障而是让“没出问题”这件事有据可查。真正推动你做巡检的往往不是某次宕机而是你答不上来“上周数据库的连接数峰值是多少”“备份到底有没有恢复过”这种问题。把巡检做成一份能交付的docx文档意味着巡检从个人经验变成团队流程谁来做、多久做一次、看哪些指标、什么数值算异常、异常后找谁全部白纸黑字写清楚。这份方案适合运维工程师、DBA、后端开发也适合刚接手一套生产库还没来得及摸清底细的人。它的产出不是一张检查表而是一套可以反复执行、能验证、能改进的闭环。2. 巡检范围和巡检项怎么定从实例到业务数据的分层2.1 巡检不只是一张表先圈好三层边界很多巡检方案写不好是因为把“数据库巡检”理解成了“连上数据库跑几条SQL”。真实的巡检至少覆盖三层操作系统与硬件层、数据库实例层、业务数据层。操作系统层面看磁盘空间、内存压力、CPU负载、文件句柄数实例层面看连接数、慢查询、死锁、主从延迟、日志增长业务数据层面看表膨胀、索引失效、碎片率、异常数据量增长。三层缺一层方案就有盲区。我一般建议先按这三层画一张矩阵表横向是检查对象纵向是检查项、采集方式、正常范围、告警阈值、负责人。画完这张表巡检方案的整体骨架就出来了。后续写文档、做脚本、定频率都是围绕这张表展开。不要一上来就想把企业级监控平台的那套搬过来先解决“能不能定时拿到这些数字”的问题。2.2 先跑第一轮一套能覆盖多数场景的最小检查清单下面这份清单适用于MySQL这类常见关系型数据库也基本能平移到PostgreSQL、达梦等产品上。第一轮不需要额外安装agent目标是半小时内把数据库的健康底数摸清楚。检查层检查项判断标准采集方式系统层磁盘剩余空间数据盘低于20%告警df -h系统层内存使用率持续高于90%且swap增长free -m系统层CPU负载load average超过核数1.5倍uptime实例层连接数使用率超过max_connections的70%SQL查询实例层慢查询数量单日超过阈值或持续增长SQL查询实例层主从延迟持续大于30秒SQL查询实例层死锁发生次数单日出现即记录SQL查询业务层最大表的数据量单表超过100GB记录趋势SQL查询这份清单不是最终版但足够让你先跑起来。跑完之后你才知道哪些指标在你的环境里是敏感的哪些常年稳定不用天天盯。巡检的成本主要由检查项数量决定清单越短越容易坚持执行。2.3 用SQL快速捞活数据半小时出第一版结果检查项定好之后采集命令要能直接复制使用。系统层面的几条Linux命令加上实例层面的几条SQL就能覆盖大多数基础场景。下面是示例。# 查看数据盘使用率重点关注挂载点 /data 或 /var/lib/mysql df -h | grep -E Filesystem|/data|/var/lib/mysql # 查看内存与swap使用情况判断是否存在内存压力 free -m # 查看系统负载对照cpu核数判断是否过载 uptime这几条命令的逻辑是磁盘满了数据库会直接只读或crash内存不足会触发swap导致性能骤降load升高往往伴随慢查询爆发。参数说明df -h以人类可读格式显示分区使用量free -m以MB为单位显示内存uptime的输出里第三个数字是15分钟平均负载和CPU核数对比才有意义。接着用SQL采集实例层的核心状态。下面以MySQL为例其他数据库语法类似思路相同。-- 连接数使用率当前连接数 / 最大连接数 SHOW VARIABLES LIKE max_connections; SHOW STATUS LIKE Threads_connected; -- 慢查询数量统计注意先确认slow_query_log已开启 SHOW GLOBAL STATUS LIKE Slow_queries; -- 主从延迟在从库上执行 SHOW SLAVE STATUS\G这些SQL的作用是拿到数字而不是直接判断好坏。连接数使用率超过70%时要关注业务峰值特征慢查询是累计值要和上次巡检的差值做对比才有效SHOW SLAVE STATUS\G需要关注Seconds_Behind_Master字段持续大于30秒就需要排查大事务或锁竞争。3. 巡检频率与值班节奏把检查变成机制而不是运动3.1 监控管告警巡检管状态两者边界要划清很多团队把巡检和监控混为一谈结果要么是重复建设要么是巡检变成一个低效的“手动监控”。监控系统的定位是实时告警出了问题立刻通知人巡检的定位则是周期性地确认系统状态是否在可控范围内并把结果留存下来作为趋势分析的依据。举个例子CPU瞬时飙到90%监控会打你电话但连接数每周缓慢增长只有巡检对比历史数据时才看得出来。所以巡检的频率不该拍脑袋定要看数据的“变化速度”。核心交易库每天巡检一次分析型库、测试库每周一次甚至每月一次都够。判断标准很简单两次巡检之间会不会有指标悄悄恶化到阈值之下而没人发现会就加密巡检不会就维持低频。3.2 每日巡检的十分钟操作固定动作固定输出每日巡检应该像晨会一样固定下来动作要少输出要稳定。我一般把每日巡检限定为一组命令加一张状态表必须能在十分钟内完成。检查项包括磁盘剩余空间、连接数使用率、主从延迟、慢查询增量、错误日志中的异常条目。# 查看MySQL错误日志中最近1小时的ERROR级别记录 grep $(date -d 1 hour ago %Y-%m-%d %H) /var/log/mysql/error.log | grep -i error # 检查主从复制状态输出重点字段 mysql -e SHOW SLAVE STATUS\G | grep -E Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master这两条命令不复杂逻辑分别是错误日志是数据库自我报告的最直接来源复制状态是主从架构下最脆弱的一环。参数说明grep的第一个条件是匹配最近一小时的时间戳前缀第二个条件是过滤包含error的行mysql -e直接执行SQL并输出结果适合脚本化调用。日报里就写这几项是否正常、异常是什么、是否需要人工介入。3.3 每周深度巡检慢查询、死锁和备份验证周度巡检解决的问题是“本周和上周比哪些数字变差了”。重中之重是三类慢查询是否增多、死锁是否出现、备份是否真正可用。慢查询增多往往意味着数据量增长或SQL执行计划发生变化死锁出现说明并发逻辑有问题备份只备份不恢复等于没有备份。-- 本周慢查询Top 10按平均耗时倒序排列 SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT / 1000000000 AS avg_ms, MAX_TIMER_WAIT / 1000000000 AS max_ms FROM performance_schema.events_statements_summary_by_digest WHERE LAST_SEEN DATE_SUB(NOW(), INTERVAL 7 DAY) ORDER BY AVG_TIMER_WAIT DESC LIMIT 10;这段SQL从performance_schema的语句摘要表里取最近七天耗时代价最高的SQL。逻辑说明按DIGEST_TEXT聚合可以归类同模板SQLCOUNT_STAR是执行次数AVG_TIMER_WAIT和MAX_TIMER_WAIT以皮秒为单位除以1000000000换算成毫秒。参数说明LAST_SEEN过滤最近七天的记录排序字段换成COUNT_STAR就能找到调用了最多次的SQL这两类往往不是同一批都要看一眼。死锁的排查在MySQL里用这条命令查看最近一次死锁信息SHOW ENGINE INNODB STATUS\G重点看LATEST DETECTED DEADLOCK段落里面记录了两个事务各自持有的锁和等待的锁。备份验证则是每月做一次恢复演练把备份恢复到临时实例上用mydumper或mysqldump导出的数据做全量比对。每周巡检的产出是一份简短报告记录异常项、趋势变化和下周关注的点不用写长篇大论。4. 巡检参数怎么设阈值、风险分级和常见坑4.1 阈值定低了会刷屏定高了等于白巡巡检方案里最容易翻车的环节是阈值设置。定低了告警刷屏团队很快会麻木真正出问题时没人看消息定高了指标一路恶化也没人发现巡检形同虚设。合理的做法是先跑两周“只记录不告警”的模式拿到基线数据后再设阈值。基线怎么算把历史数据按天分组取P50和P90分位值日常用P90作为关注线连续三天超过P90才升级为告警事件。下面是MySQL巡检中常用的基础阈值表可作为第一版参考值实际上线前务必按自己的基线调整。风险等级分为三级P2是关注持续加重才处理P1是介入需要当天排查P0是故障需要立即响应。指标参考阈值风险等级说明连接数使用率70% 关注85% 告警P1超过85%可能触发拒绝新连接磁盘空间剩余低于20% 关注低于10% 告警P0磁盘写满是会导致数据库只读的慢查询数单日增长超过50%P2关注SQL执行计划变化主从延迟持续30秒以上P1延迟会导致从库读不到最新数据死锁次数单日大于0P1需要分析死锁日志确认原因Buffer Pool命中率低于95%P2命中率低意味着大量磁盘IO4.2 几个必调的参数从“能跑”到“跑得稳”巡检方案中要重点关注的参数不限于操作系统层数据库自身的几个核心参数直接决定稳定性。max_connections设太大内存会被连接池吃满innodb_buffer_pool_size设太小热点数据频繁落盘binlog_expire_logs_seconds设置过长磁盘迟早被日志占满。下面这组参数是巡检时建议核对的基础项-- 查看关键参数当前配置 SHOW VARIABLES WHERE Variable_name IN ( max_connections, innodb_buffer_pool_size, binlog_expire_logs_seconds, slow_query_log, long_query_time, sync_binlog );逻辑说明这条SQL一次性把六个核心参数全部捞出来避免多次执行。参数说明innodb_buffer_pool_size通常是物理内存的60%到70%binlog_expire_logs_seconds建议按至少保留72小时来设太短会导致时间点恢复能力不足slow_query_log必须为ONlong_query_time设为1秒比较合理关闭慢查询日志等于巡检少了一只眼睛sync_binlog设为1时每次事务提交都刷盘数据安全最好但性能有损耗具体取舍要看业务容忍度。4.3 从巡检里看出来的常见问题死锁、慢查询和备份失效巡检跑通了之后真正考验人的是把“记录”变成“判断”。死锁这个问题单次出现不算故障但如果一周出现多次就要查业务代码里锁的获取顺序是否一致慢查询的根本解法也不是加索引而是先看EXPLAIN分析是不是查询条件导致全表扫描备份失效最具隐蔽性备份任务报“成功”不代表备份可用恢复出来的数据可能缺少关键表。判断备份可用性的标准做法是每月做一次实际恢复演练在临时实例上导入备份数据执行几条统计SQL验证行数一致性。-- 在恢复后的临时实例上执行对比源库的行数 SELECT COUNT(*) AS backup_row_count FROM orders; SELECT COUNT(*) AS source_row_count FROM source_orders;这段SQL的逻辑是手动对比备份恢复后的数据行数和源库的行数差异超出预期就说明备份链路有数据丢失。参数说明orders是恢复后的表source_orders是从源库导出导入的快照表两条SQL结果一致才是初步验证通过。5. 巡检方案docx怎么组织从巡检项到可执行手册5.1 文档结构设计让新来的DBA也敢照着做一份好的巡检方案docx模板上至少要有六个部分巡检目的与适用范围、巡检对象清单、巡检频率与时间窗口、巡检操作步骤、阈值与判定标准、异常处理与升级路径。这些内容缺一不可。巡检目的解决“为什么做”适用范围解决“管哪些库”操作步骤解决“怎么做”阈值标准解决“好不好”异常升级解决“出了问题谁负责”。很多人写巡检方案只写“检查连接数”“检查慢查询”这种一句话根本不写命令和阈值。这等于给了菜谱但不告诉你要加多少盐。最实用的写法是每个巡检项下包含检查命令或SQL、预期输出样例、正常范围、异常时怎么办四个要素缺一个就不合格。5.2 巡检方案docx的章节模板直接抄作业的版本如果你已经在用Markdown写文档用下面的结构就够了输出Word时用pandoc转换。模板的每一节都是可执行的操作步骤而不是一句岗位职责描述。# 数据库巡检方案 ## 1. 巡检范围 列出所有实例的IP、端口、角色、业务归属。 ## 2. 巡检频率 - 每日连接数、磁盘、主从延迟、错误日志 - 每周慢查询、死锁、表数据量增长 - 每月备份恢复演练、参数核对 ## 3. 巡检操作步骤 ### 3.1 系统层检查 写明命令、输出样例和判定标准。 ### 3.2 实例层检查 写明SQL、输出样例和判定标准。 ## 4. 阈值与风险分级 附阈值表格标注P0/P1/P2。 ## 5. 异常处理流程 写明各等级异常的响应时限、处理人和上报路径。 ## 6. 巡检记录表 每次巡检填一行日期、巡检人、关键指标、异常项、备注。这套结构的核心是把巡检方案当作一份可执行手册来写。模板中的表格、SQL、判定标准都来自前面章节的实际操作内容不要另起炉灶写一套和实际执行不一致的文档。5.3 用pandoc把Markdown转成docx一次成型写巡检方案时我用Markdown维护更新定稿之后才转成docx。这样可以避免直接在Word里频繁调整格式。转换命令如下# 将Markdown巡检方案转换为docx并自动生成目录 pandoc 数据库巡检方案.md \ -o 数据库巡检方案.docx \ --toc \ --toc-depth2 \ -V langzh-CN这条命令的作用是把Markdown转成带目录的Word文档。参数说明--toc生成目录--toc-depth2只保留两级目录-V langzh-CN告诉pandoc文档语言是中文避免Word校验中文文本时报错。如果文档里需要插入多个巡检截图建议在Word里手工补图pandoc对图片路径的处理不够直观转完后再调整图片位置效率更高。6. 用覆盖率、误报率和响应时效验证巡检方案本身6.1 把巡检报告变成可对比的数据每周留一条可复算的记录巡检方案运行一个月后真正需要验证的不是“检了几次”而是三件事巡检覆盖了应该覆盖的所有实例吗误报率高不高异常发现到响应到底花了多久覆盖率的意思是文档里写了要巡检10个实例实际巡检记录里是否都有这10个实例的报告。误报率的意思是告警里有多少其实是阈值设低导致的无害记录。响应时效是异常升级后到有人处理的时间差。把这些量化出来并不难。给每个实例一个编号每次巡检后在记录表里补一行数据。一周下来统计实例出现次数和清单对比就知道覆盖率。误报率的统计方式是每周把告警清单过一遍凡是判断为“无需处理”的都标记为误报。响应时效则需要配合值班记录拿异常发现时间和处理动作时间做差。这三个数才是巡检方案本身的KPI。6.2 检查清单的更新节奏跟着故障复盘走巡检方案不是写完就冻结的文档。每出现一次线上故障复盘时都要问一个问题这次故障在巡检清单里有没有对应的检查项如果没有就补进去如果有但没拦住就要看是阈值的锅还是频率的锅。例如某次磁盘被binlog打满复盘后就应该把binlog总量和应用增长速率加入巡检项。这样巡检方案才会越来越贴近实际风险。具体操作上我一般用一个小脚本从巡检记录表中提取最近五周的指标增量自动对比当周和上周的差异。# 最近5周巡检记录汇总输出连接数、磁盘、主从延迟三项趋势 cat 巡检记录.csv | awk -F, NR 1 { week[$1] $1; conn[$1] $2; disk[$1] $3; lag[$1] $4; } END { for (w in week) { printf %s 连接数均值%d 磁盘剩余%s 主从延迟%s\n, w, conn[w]/7, disk[w], lag[w]; } } | sort这段awk脚本的逻辑很简单按周聚合巡检记录计算连接数均值并取出磁盘和延迟的最后一次值。参数说明巡检记录.csv需要至少有四列分别是日期、连接数、磁盘剩余百分比、主从延迟秒数列之间用逗号分隔。conn[w]/7假设每天一条记录一周七条均值才有意义如果巡检频率不是每日这个除数要改成实际巡检次数。把这三个指标变成每周必看的数据后巡检方案的验证就闭环了。覆盖率低就补巡检误报率高就调阈值响应慢就改流程。本文还有配套的精品资源点击获取 数据库巡检方案实战：从检查清单到docx可执行手册
简介一份面向数据库管理员与运维人员的《数据库巡检方案》Word文档系统梳理Oracle数据库日常健康巡检的关键环节包括实例与后台进程状态、文件系统空间、运行日志与监听日志清理以及性能监控、备份恢复、权限安全和参数调整等注意事项可作为日常巡检的清单式参考。资源为单个docx文件约2MB便于下载后直接查阅或打印执行。内容结合常用命令示例如查看SID、使用df/bdf检查磁盘空间、定位alert日志、通过RMAN确认备份结果并给出保留最近错误信息、设置滚动机制等日志清理原则。读者可据此快速形成规范巡检流程预防空间不足或日志膨胀引发故障提升数据库稳定性与运维效率。目前已有136人学习适合数据库运维人员作为日常操作模板。1. 数据库巡检方案先明白它到底在防什么数据库巡检最大的价值不是发现故障而是让“没出问题”这件事有据可查。真正推动你做巡检的往往不是某次宕机而是你答不上来“上周数据库的连接数峰值是多少”“备份到底有没有恢复过”这种问题。把巡检做成一份能交付的docx文档意味着巡检从个人经验变成团队流程谁来做、多久做一次、看哪些指标、什么数值算异常、异常后找谁全部白纸黑字写清楚。这份方案适合运维工程师、DBA、后端开发也适合刚接手一套生产库还没来得及摸清底细的人。它的产出不是一张检查表而是一套可以反复执行、能验证、能改进的闭环。2. 巡检范围和巡检项怎么定从实例到业务数据的分层2.1 巡检不只是一张表先圈好三层边界很多巡检方案写不好是因为把“数据库巡检”理解成了“连上数据库跑几条SQL”。真实的巡检至少覆盖三层操作系统与硬件层、数据库实例层、业务数据层。操作系统层面看磁盘空间、内存压力、CPU负载、文件句柄数实例层面看连接数、慢查询、死锁、主从延迟、日志增长业务数据层面看表膨胀、索引失效、碎片率、异常数据量增长。三层缺一层方案就有盲区。我一般建议先按这三层画一张矩阵表横向是检查对象纵向是检查项、采集方式、正常范围、告警阈值、负责人。画完这张表巡检方案的整体骨架就出来了。后续写文档、做脚本、定频率都是围绕这张表展开。不要一上来就想把企业级监控平台的那套搬过来先解决“能不能定时拿到这些数字”的问题。2.2 先跑第一轮一套能覆盖多数场景的最小检查清单下面这份清单适用于MySQL这类常见关系型数据库也基本能平移到PostgreSQL、达梦等产品上。第一轮不需要额外安装agent目标是半小时内把数据库的健康底数摸清楚。检查层检查项判断标准采集方式系统层磁盘剩余空间数据盘低于20%告警df -h系统层内存使用率持续高于90%且swap增长free -m系统层CPU负载load average超过核数1.5倍uptime实例层连接数使用率超过max_connections的70%SQL查询实例层慢查询数量单日超过阈值或持续增长SQL查询实例层主从延迟持续大于30秒SQL查询实例层死锁发生次数单日出现即记录SQL查询业务层最大表的数据量单表超过100GB记录趋势SQL查询这份清单不是最终版但足够让你先跑起来。跑完之后你才知道哪些指标在你的环境里是敏感的哪些常年稳定不用天天盯。巡检的成本主要由检查项数量决定清单越短越容易坚持执行。2.3 用SQL快速捞活数据半小时出第一版结果检查项定好之后采集命令要能直接复制使用。系统层面的几条Linux命令加上实例层面的几条SQL就能覆盖大多数基础场景。下面是示例。# 查看数据盘使用率重点关注挂载点 /data 或 /var/lib/mysql df -h | grep -E Filesystem|/data|/var/lib/mysql # 查看内存与swap使用情况判断是否存在内存压力 free -m # 查看系统负载对照cpu核数判断是否过载 uptime这几条命令的逻辑是磁盘满了数据库会直接只读或crash内存不足会触发swap导致性能骤降load升高往往伴随慢查询爆发。参数说明df -h以人类可读格式显示分区使用量free -m以MB为单位显示内存uptime的输出里第三个数字是15分钟平均负载和CPU核数对比才有意义。接着用SQL采集实例层的核心状态。下面以MySQL为例其他数据库语法类似思路相同。-- 连接数使用率当前连接数 / 最大连接数 SHOW VARIABLES LIKE max_connections; SHOW STATUS LIKE Threads_connected; -- 慢查询数量统计注意先确认slow_query_log已开启 SHOW GLOBAL STATUS LIKE Slow_queries; -- 主从延迟在从库上执行 SHOW SLAVE STATUS\G这些SQL的作用是拿到数字而不是直接判断好坏。连接数使用率超过70%时要关注业务峰值特征慢查询是累计值要和上次巡检的差值做对比才有效SHOW SLAVE STATUS\G需要关注Seconds_Behind_Master字段持续大于30秒就需要排查大事务或锁竞争。3. 巡检频率与值班节奏把检查变成机制而不是运动3.1 监控管告警巡检管状态两者边界要划清很多团队把巡检和监控混为一谈结果要么是重复建设要么是巡检变成一个低效的“手动监控”。监控系统的定位是实时告警出了问题立刻通知人巡检的定位则是周期性地确认系统状态是否在可控范围内并把结果留存下来作为趋势分析的依据。举个例子CPU瞬时飙到90%监控会打你电话但连接数每周缓慢增长只有巡检对比历史数据时才看得出来。所以巡检的频率不该拍脑袋定要看数据的“变化速度”。核心交易库每天巡检一次分析型库、测试库每周一次甚至每月一次都够。判断标准很简单两次巡检之间会不会有指标悄悄恶化到阈值之下而没人发现会就加密巡检不会就维持低频。3.2 每日巡检的十分钟操作固定动作固定输出每日巡检应该像晨会一样固定下来动作要少输出要稳定。我一般把每日巡检限定为一组命令加一张状态表必须能在十分钟内完成。检查项包括磁盘剩余空间、连接数使用率、主从延迟、慢查询增量、错误日志中的异常条目。# 查看MySQL错误日志中最近1小时的ERROR级别记录 grep $(date -d 1 hour ago %Y-%m-%d %H) /var/log/mysql/error.log | grep -i error # 检查主从复制状态输出重点字段 mysql -e SHOW SLAVE STATUS\G | grep -E Slave_IO_Running|Slave_SQL_Running|Seconds_Behind_Master这两条命令不复杂逻辑分别是错误日志是数据库自我报告的最直接来源复制状态是主从架构下最脆弱的一环。参数说明grep的第一个条件是匹配最近一小时的时间戳前缀第二个条件是过滤包含error的行mysql -e直接执行SQL并输出结果适合脚本化调用。日报里就写这几项是否正常、异常是什么、是否需要人工介入。3.3 每周深度巡检慢查询、死锁和备份验证周度巡检解决的问题是“本周和上周比哪些数字变差了”。重中之重是三类慢查询是否增多、死锁是否出现、备份是否真正可用。慢查询增多往往意味着数据量增长或SQL执行计划发生变化死锁出现说明并发逻辑有问题备份只备份不恢复等于没有备份。-- 本周慢查询Top 10按平均耗时倒序排列 SELECT SCHEMA_NAME, DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT / 1000000000 AS avg_ms, MAX_TIMER_WAIT / 1000000000 AS max_ms FROM performance_schema.events_statements_summary_by_digest WHERE LAST_SEEN DATE_SUB(NOW(), INTERVAL 7 DAY) ORDER BY AVG_TIMER_WAIT DESC LIMIT 10;这段SQL从performance_schema的语句摘要表里取最近七天耗时代价最高的SQL。逻辑说明按DIGEST_TEXT聚合可以归类同模板SQLCOUNT_STAR是执行次数AVG_TIMER_WAIT和MAX_TIMER_WAIT以皮秒为单位除以1000000000换算成毫秒。参数说明LAST_SEEN过滤最近七天的记录排序字段换成COUNT_STAR就能找到调用了最多次的SQL这两类往往不是同一批都要看一眼。死锁的排查在MySQL里用这条命令查看最近一次死锁信息SHOW ENGINE INNODB STATUS\G重点看LATEST DETECTED DEADLOCK段落里面记录了两个事务各自持有的锁和等待的锁。备份验证则是每月做一次恢复演练把备份恢复到临时实例上用mydumper或mysqldump导出的数据做全量比对。每周巡检的产出是一份简短报告记录异常项、趋势变化和下周关注的点不用写长篇大论。4. 巡检参数怎么设阈值、风险分级和常见坑4.1 阈值定低了会刷屏定高了等于白巡巡检方案里最容易翻车的环节是阈值设置。定低了告警刷屏团队很快会麻木真正出问题时没人看消息定高了指标一路恶化也没人发现巡检形同虚设。合理的做法是先跑两周“只记录不告警”的模式拿到基线数据后再设阈值。基线怎么算把历史数据按天分组取P50和P90分位值日常用P90作为关注线连续三天超过P90才升级为告警事件。下面是MySQL巡检中常用的基础阈值表可作为第一版参考值实际上线前务必按自己的基线调整。风险等级分为三级P2是关注持续加重才处理P1是介入需要当天排查P0是故障需要立即响应。指标参考阈值风险等级说明连接数使用率70% 关注85% 告警P1超过85%可能触发拒绝新连接磁盘空间剩余低于20% 关注低于10% 告警P0磁盘写满是会导致数据库只读的慢查询数单日增长超过50%P2关注SQL执行计划变化主从延迟持续30秒以上P1延迟会导致从库读不到最新数据死锁次数单日大于0P1需要分析死锁日志确认原因Buffer Pool命中率低于95%P2命中率低意味着大量磁盘IO4.2 几个必调的参数从“能跑”到“跑得稳”巡检方案中要重点关注的参数不限于操作系统层数据库自身的几个核心参数直接决定稳定性。max_connections设太大内存会被连接池吃满innodb_buffer_pool_size设太小热点数据频繁落盘binlog_expire_logs_seconds设置过长磁盘迟早被日志占满。下面这组参数是巡检时建议核对的基础项-- 查看关键参数当前配置 SHOW VARIABLES WHERE Variable_name IN ( max_connections, innodb_buffer_pool_size, binlog_expire_logs_seconds, slow_query_log, long_query_time, sync_binlog );逻辑说明这条SQL一次性把六个核心参数全部捞出来避免多次执行。参数说明innodb_buffer_pool_size通常是物理内存的60%到70%binlog_expire_logs_seconds建议按至少保留72小时来设太短会导致时间点恢复能力不足slow_query_log必须为ONlong_query_time设为1秒比较合理关闭慢查询日志等于巡检少了一只眼睛sync_binlog设为1时每次事务提交都刷盘数据安全最好但性能有损耗具体取舍要看业务容忍度。4.3 从巡检里看出来的常见问题死锁、慢查询和备份失效巡检跑通了之后真正考验人的是把“记录”变成“判断”。死锁这个问题单次出现不算故障但如果一周出现多次就要查业务代码里锁的获取顺序是否一致慢查询的根本解法也不是加索引而是先看EXPLAIN分析是不是查询条件导致全表扫描备份失效最具隐蔽性备份任务报“成功”不代表备份可用恢复出来的数据可能缺少关键表。判断备份可用性的标准做法是每月做一次实际恢复演练在临时实例上导入备份数据执行几条统计SQL验证行数一致性。-- 在恢复后的临时实例上执行对比源库的行数 SELECT COUNT(*) AS backup_row_count FROM orders; SELECT COUNT(*) AS source_row_count FROM source_orders;这段SQL的逻辑是手动对比备份恢复后的数据行数和源库的行数差异超出预期就说明备份链路有数据丢失。参数说明orders是恢复后的表source_orders是从源库导出导入的快照表两条SQL结果一致才是初步验证通过。5. 巡检方案docx怎么组织从巡检项到可执行手册5.1 文档结构设计让新来的DBA也敢照着做一份好的巡检方案docx模板上至少要有六个部分巡检目的与适用范围、巡检对象清单、巡检频率与时间窗口、巡检操作步骤、阈值与判定标准、异常处理与升级路径。这些内容缺一不可。巡检目的解决“为什么做”适用范围解决“管哪些库”操作步骤解决“怎么做”阈值标准解决“好不好”异常升级解决“出了问题谁负责”。很多人写巡检方案只写“检查连接数”“检查慢查询”这种一句话根本不写命令和阈值。这等于给了菜谱但不告诉你要加多少盐。最实用的写法是每个巡检项下包含检查命令或SQL、预期输出样例、正常范围、异常时怎么办四个要素缺一个就不合格。5.2 巡检方案docx的章节模板直接抄作业的版本如果你已经在用Markdown写文档用下面的结构就够了输出Word时用pandoc转换。模板的每一节都是可执行的操作步骤而不是一句岗位职责描述。# 数据库巡检方案 ## 1. 巡检范围 列出所有实例的IP、端口、角色、业务归属。 ## 2. 巡检频率 - 每日连接数、磁盘、主从延迟、错误日志 - 每周慢查询、死锁、表数据量增长 - 每月备份恢复演练、参数核对 ## 3. 巡检操作步骤 ### 3.1 系统层检查 写明命令、输出样例和判定标准。 ### 3.2 实例层检查 写明SQL、输出样例和判定标准。 ## 4. 阈值与风险分级 附阈值表格标注P0/P1/P2。 ## 5. 异常处理流程 写明各等级异常的响应时限、处理人和上报路径。 ## 6. 巡检记录表 每次巡检填一行日期、巡检人、关键指标、异常项、备注。这套结构的核心是把巡检方案当作一份可执行手册来写。模板中的表格、SQL、判定标准都来自前面章节的实际操作内容不要另起炉灶写一套和实际执行不一致的文档。5.3 用pandoc把Markdown转成docx一次成型写巡检方案时我用Markdown维护更新定稿之后才转成docx。这样可以避免直接在Word里频繁调整格式。转换命令如下# 将Markdown巡检方案转换为docx并自动生成目录 pandoc 数据库巡检方案.md \ -o 数据库巡检方案.docx \ --toc \ --toc-depth2 \ -V langzh-CN这条命令的作用是把Markdown转成带目录的Word文档。参数说明--toc生成目录--toc-depth2只保留两级目录-V langzh-CN告诉pandoc文档语言是中文避免Word校验中文文本时报错。如果文档里需要插入多个巡检截图建议在Word里手工补图pandoc对图片路径的处理不够直观转完后再调整图片位置效率更高。6. 用覆盖率、误报率和响应时效验证巡检方案本身6.1 把巡检报告变成可对比的数据每周留一条可复算的记录巡检方案运行一个月后真正需要验证的不是“检了几次”而是三件事巡检覆盖了应该覆盖的所有实例吗误报率高不高异常发现到响应到底花了多久覆盖率的意思是文档里写了要巡检10个实例实际巡检记录里是否都有这10个实例的报告。误报率的意思是告警里有多少其实是阈值设低导致的无害记录。响应时效是异常升级后到有人处理的时间差。把这些量化出来并不难。给每个实例一个编号每次巡检后在记录表里补一行数据。一周下来统计实例出现次数和清单对比就知道覆盖率。误报率的统计方式是每周把告警清单过一遍凡是判断为“无需处理”的都标记为误报。响应时效则需要配合值班记录拿异常发现时间和处理动作时间做差。这三个数才是巡检方案本身的KPI。6.2 检查清单的更新节奏跟着故障复盘走巡检方案不是写完就冻结的文档。每出现一次线上故障复盘时都要问一个问题这次故障在巡检清单里有没有对应的检查项如果没有就补进去如果有但没拦住就要看是阈值的锅还是频率的锅。例如某次磁盘被binlog打满复盘后就应该把binlog总量和应用增长速率加入巡检项。这样巡检方案才会越来越贴近实际风险。具体操作上我一般用一个小脚本从巡检记录表中提取最近五周的指标增量自动对比当周和上周的差异。# 最近5周巡检记录汇总输出连接数、磁盘、主从延迟三项趋势 cat 巡检记录.csv | awk -F, NR 1 { week[$1] $1; conn[$1] $2; disk[$1] $3; lag[$1] $4; } END { for (w in week) { printf %s 连接数均值%d 磁盘剩余%s 主从延迟%s\n, w, conn[w]/7, disk[w], lag[w]; } } | sort这段awk脚本的逻辑很简单按周聚合巡检记录计算连接数均值并取出磁盘和延迟的最后一次值。参数说明巡检记录.csv需要至少有四列分别是日期、连接数、磁盘剩余百分比、主从延迟秒数列之间用逗号分隔。conn[w]/7假设每天一条记录一周七条均值才有意义如果巡检频率不是每日这个除数要改成实际巡检次数。把这三个指标变成每周必看的数据后巡检方案的验证就闭环了。覆盖率低就补巡检误报率高就调阈值响应慢就改流程。本文还有配套的精品资源点击获取