------ 系列第四篇：主从、慢查询、锁、备份、磁盘，一份体检剧本全查完，报告自动生成
本篇定位： DBA 巡检清单里那几十项检查，过去要开四五个窗口敲半天。这篇把主从复制、慢查询、锁等待、备份有效性、磁盘水位五大模块做成一份 AI 巡检剧本，一句话触发，报告自动生成，命令全部可照抄。
目录
- 一、DBA 巡检清单，到底在查什么
- 二、体检剧本全文（直接复制）
- 三、五大模块逐项解读
- 四、体检报告长什么样
- 五、把体检变成值守：定时 + 告警
- 六、三个真实案例复盘
- 七、常见问题
一、DBA 巡检清单，到底在查什么
老 DBA 巡检时的肌肉记忆，其实就五大块：
| 模块 | 核心问题 | 出事的后果 |
|---|---|---|
| 主从复制 | 从库延迟多少？SQL 线程还活着吗？ | 读到旧数据、切换失败 |
| 慢查询 | 今天慢 SQL 几条？最慢那条是谁？ | 连接池被拖垮，全站卡 |
| 锁与等待 | 有没有长事务？MDL 锁堵 DDL？ | 一条 DDL 卡死整表 |
| 备份有效性 | 备份文件在吗？多大了？能恢复吗？ | 真出事时没有后路 |
| 资源水位 | 磁盘、连接数、buffer pool 命中率 | 磁盘满直接库挂 |
**巡检的本质不是"看"，而是"按清单确认没有意外"。**这正是最容易被 AI 接管的劳动------清单明确、判定标准明确、输出格式明确。
二、体检剧本全文（直接复制）
前提：AI SSH 运维 Agent 已录入 mysql-master（10.10.10.101）和 mysql-slave（10.10.10.102），并给 Agent 提供一个有 SHOW 权限的巡检账号（建议只授 PROCESS、REPLICATION CLIENT、SHOW DATABASES，坚决不给写权限）。
对 AI 说这一段（整段复制）：
text
对 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% 就要警惕内存配置或索引问题。
四、体检报告长什么样
真实体检报告的节选（脱敏）：
text
MySQL 体检报告 2026-10-12 09:30 （mysql-master / mysql-slave）
【1 主从复制】✅ 正常
IO/SQL 线程均 Yes，延迟 2 秒，无 Last_IO_Error。
【2 慢查询】⚠️ 预警
今日 Slow_queries 增量 17（昨日 3）。
最慢 SQL：SELECT * 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/500；buffer pool 命中率 99.2%。
总体：2 项正常，1 项预警，1 项告警。
优先处理：kill 3352 长事务 → 跟进 17 条慢 SQL 的索引方案。这份报告的每一行都可以点开看原始命令和输出，不是 AI 编的"感觉"，全部有据可查。
五、把体检变成值守：定时 + 告警
单次体检只是开始，配上值守才是完全体：
text
每天早上 9 点对两台 MySQL 跑一次上面的全量体检剧本，
报告发到值班群；
主从延迟连续 3 次 > 60 秒，或磁盘 > 85%，立即触发 WebHook 告警。再补一条轻量的分钟级守望：
text
每 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，体检只读，动手的事人工或二次确认后再授权。
Q：AI 会不会直接 kill 生产会话？
剧本里写明"只查不改"，它最多给出 kill 建议；你回复"执行 kill 3352"它才会动手，且这笔操作全程留痕。
Q：从库延迟抖动怎么减少误报？
判定线从"瞬时 > 60 秒"改成"连续 3 次 > 60 秒"，再加上"低于 10 秒自动恢复不告警"，基本清净。
Q：能体检分库分表集群吗？
可以，把每个实例录成一台主机，剧本里列出实例清单即可；Agent 会逐个执行并汇总成一份大报告。
本文为「AI SSH 运维 Agent」系列第 4/8 篇。后续篇目：《多模态看图实战》《管的不只是 Linux》《SFTP 批量配置下发》《团队安全落地指南》------从"能聊天"到"能值守"再到"能体检"，一步步把 AI 运维用深。