★ FEATURED ARTICLE —— 系列第四篇主从、慢查询、锁、备份、磁盘一份体检剧本全查完报告自动生成本篇定位DBA 巡检清单里那几十项检查过去要开四五个窗口敲半天。这篇把主从复制、慢查询、锁等待、备份有效性、磁盘水位五大模块做成一份 AI 巡检剧本一句话触发报告自动生成命令全部可照抄。目录一、DBA 巡检清单到底在查什么二、体检剧本全文直接复制三、五大模块逐项解读四、体检报告长什么样五、把体检变成值守定时 告警六、三个真实案例复盘七、常见问题一、DBA 巡检清单到底在查什么老 DBA 巡检时的肌肉记忆其实就五大块模块核心问题出事的后果主从复制从库延迟多少SQL 线程还活着吗读到旧数据、切换失败慢查询今天慢 SQL 几条最慢那条是谁连接池被拖垮全站卡锁与等待有没有长事务MDL 锁堵 DDL一条 DDL 卡死整表备份有效性备份文件在吗多大了能恢复吗真出事时没有后路资源水位磁盘、连接数、buffer pool 命中率磁盘满直接库挂巡检的本质不是看而是按清单确认没有意外。这正是最容易被 AI 接管的劳动——清单明确、判定标准明确、输出格式明确。二、体检剧本全文直接复制前提AI SSH 运维 Agent 已录入mysql-master10.10.10.101和mysql-slave10.10.10.102并给 Agent 提供一个有SHOW权限的巡检账号建议只授 PROCESS、REPLICATION CLIENT、SHOW DATABASES坚决不给写权限。对 AI 说这一段整段复制对 mysql-master 和 mysql-slave 做一次 MySQL 全量体检 只查不改逐项输出 【1 主从复制】SHOW SLAVE STATUS\G 中的 Slave_IO_Running / Slave_SQL_Running / Seconds_Behind_Master / Last_IO_Error延迟超过 60 秒标预警 【2 慢查询】SHOW GLOBAL STATUS LIKE Slow_queries 的今日增量 再看慢日志目录里今天最慢的 3 条 SQL 摘要 【3 锁与长事务】information_schema.innodb_trx 中 运行超过 60 秒的事务及 processlist 里 State 含 Waiting for table metadata lock 的连接 【4 备份】检查 /data/backup 下最近一份备份的 文件时间与大小超过 24 小时未更新标红 【5 资源】磁盘使用率重点 / 和 /data、 SHOW GLOBAL STATUS 的 Threads_connected / Max_connections、 Innodb_buffer_pool_read_requests 与 reads 的命中率 最后汇总成报告每项【正常/预警/告警】结论 证据数值 建议。剧本三要素查什么具体到命令和字段、判定线60 秒、24 小时、80%、输出格式结论 证据 建议。写清这三样AI 的体检报告质量非常稳定。三、五大模块逐项解读1. 主从复制Seconds_Behind_Master是最容易被误读的字段——从库 IO 线程断了它可能显示 0。所以剧本里强制同时看Slave_IO_Running和Last_IO_Error三个字段交叉验证才下结论。2. 慢查询Slow_queries是累计值剧本特意要求今日增量并和昨天对比光有计数没用要抓到具体 SQL。AI 会去慢日志里把最慢的三条抠出来附上执行时间和扫描行数。3. 锁与长事务innodb_trx超过 60 秒的事务是很多莫名其妙的根源——一个忘提交的会话能堵住整张表的 DDL。Waiting for table metadata lock这个 State 值一出现基本可以断定有长事务挡路。4. 备份有效性注意剧本查的是最近一份备份的时间与大小不是备份任务配了没。备份任务配了但连续一周没产出新文件等于没有备份——这是巡检里最值钱的一条。5. 资源水位连接数看的是Threads_connected / Max_connections比例buffer pool 命中率低于 95% 就要警惕内存配置或索引问题。四、体检报告长什么样真实体检报告的节选脱敏MySQL 体检报告 2026-10-12 09:30 mysql-master / mysql-slave 【1 主从复制】✅ 正常 IO/SQL 线程均 Yes延迟 2 秒无 Last_IO_Error。 【2 慢查询】⚠️ 预警 今日 Slow_queries 增量 17昨日 3。 最慢 SQLSELECT * FROM orders WHERE user_id? AND status? 执行 11.2s扫描 210 万行orders 表缺 (user_id,status) 联合索引。 建议加索引前先确认该表写入峰值时段低峰期执行 online DDL。 【3 锁与长事务】❌ 告警 发现 1 个运行 1842 秒的休眠事务连接 3352来自报表机 10.10.10.88。 建议确认报表机是否泄漏连接kill 3352 后观察 MDL 等待是否消失。 【4 备份】✅ 正常 最近备份 2026-10-12 02:00大小 41G与前日持平。 【5 资源】✅ 正常 磁盘 /data 63%连接 86/500buffer pool 命中率 99.2%。 总体2 项正常1 项预警1 项告警。 优先处理kill 3352 长事务 → 跟进 17 条慢 SQL 的索引方案。这份报告的每一行都可以点开看原始命令和输出不是 AI 编的感觉全部有据可查。五、把体检变成值守定时 告警单次体检只是开始配上值守才是完全体每天早上 9 点对两台 MySQL 跑一次上面的全量体检剧本 报告发到值班群 主从延迟连续 3 次 60 秒或磁盘 85%立即触发 WebHook 告警。再补一条轻量的分钟级守望每 10 分钟只检查两台 MySQL 的 3306 端口和 mysqld 进程 连续 3 次异常才告警告警消息带上 AI 的初步诊断。分层逻辑分钟级只管活着没天级体检管健康不健康。两层各司其职就不会互相淹没。六、三个真实案例复盘案例 1报表机泄漏连接。体检连续三天报长事务 1800 秒源头都是报表机。根因是报表程序异常退出不回滚连接。修复后 MDL 等待告警从此绝迹。案例 2慢 SQL 突增 5 倍。值守告警 Slow_queries 异常AI 诊断指向一条新上线的运营查询。加联合索引后扫描行数从 210 万降到 3000从发现到解决一个上午。案例 3备份悄悄停了。体检报告最近备份 6 天前追查发现备份机证书过期导致任务静默失败。这条体检项救的可能不止是年终奖。七、常见问题Q体检账号权限怎么给才安全只给 PROCESS、REPLICATION CLIENT、SHOW DATABASES、SELECT查慢日志需要。不给任何写权限、不给 FILE体检只读动手的事人工或二次确认后再授权。QAI 会不会直接 kill 生产会话剧本里写明只查不改它最多给出 kill 建议你回复执行 kill 3352它才会动手且这笔操作全程留痕。Q从库延迟抖动怎么减少误报判定线从瞬时 60 秒改成连续 3 次 60 秒再加上低于 10 秒自动恢复不告警基本清净。Q能体检分库分表集群吗可以把每个实例录成一台主机剧本里列出实例清单即可Agent 会逐个执行并汇总成一份大报告。本文为「AI SSH 运维 Agent」系列第 4/8 篇。后续篇目《多模态看图实战》《管的不只是 Linux》《SFTP 批量配置下发》《团队安全落地指南》——从能聊天到能值守再到能体检一步步把 AI 运维用深。
阅读完成 · 觉得有帮助？
