运维场景
在数据库日常运维中，企业通常面临以下巡检管理挑战：
巡检覆盖不全、人工效率低：传统数据库巡检依赖 DBA 手动登录控制台，逐实例查看监控指标、检查健康状态，数百个实例的周度巡检往往耗时数天。多地域、多引擎的数据库资产分布进一步增加了巡检复杂度，容易出现遗漏和盲区。
巡检深度不足、分析浮于表面：常规巡检仅检查当前指标是否超阈值，缺少对资源使用趋势、风险事件和慢 SQL/慢请求的深度分析。死锁、长事务、大表、自增键耗尽等隐患难以在一次巡检中全面覆盖，往往在问题发生后才被动响应。
慢 SQL/慢请求治理缺乏闭环：慢 SQL 日志和慢请求日志数量庞大，DBA 难以逐条分析根因。高频慢 SQL 持续消耗数据库资源却无人治理，形成长期性能隐患。
巡检报告难沉淀、经验难复用：巡检结果分散在聊天记录和个人笔记中，缺乏标准化、可归档的报告产出。不同 DBA 的巡检深度和关注点不一致，巡检质量参差不齐，难以形成可追溯、可对比的巡检基线。
多引擎巡检碎片化：MySQL、PostgreSQL、Distributed Cache（兼容 Redis）、MongoDB 等不同数据库引擎各有巡检侧重点，传统方式需要分别登录不同控制台、使用不同工具，巡检流程割裂、标准不统一。
解决方案
依托 DatabaseClaw 巡检 Skill 的统一入口路由能力，自动识别数据库产品类型和用户意图，分发到对应的数据库引擎巡检 Skill 自动进行巡检分析。
方案优势
四层数据模型、AI 高效消费：原始时序数据在脚本内完成统计和异常检测，精炼为结构化数据后供 AI 按需分段读取生成报告。原始数据不传给 AI，stdout 仅输出约 2KB 摘要，大幅降低 Token 消耗和超时风险。
按需专项巡检：支持只执行部分巡检项/巡检模块，数据拉取层同步只获取相关数据，避免无效 API 调用。例如“只看慢 SQL”、“只巡检锁和长事务”、“跳过空间分析”。
历史风险追踪：通过持久化的风险登记簿，记录所有活跃风险，每次巡检时自动与上次对比，标记风险状态变化（新增/持续/恶化/缓解/复发/已恢复），形成连续观测链。
全引擎标准化报告：各引擎巡检报告统一骨架（总体结论→风险汇总→实例健康总览→数据来源→专项分析→历史追踪→周度结论→数据缺口），仅展示超阈值异常实例，噪声低、可读性强。
纯只读零风险：全部数据采集仅调用只读 API（DescribeDBInstances / GetMonitorData / DBbrain Describe* 等），不修改任何实例配置，零实例变更风险。
应用场景
场景 | 核心痛点 | 方案关键能力 | 推荐调度策略 |
日常周度巡检 | 实例多、人工巡检耗时数天 | 统一入口自动路由 + 四层数据模型 + 标准化报告归档 | 每周 1 次，全地域全引擎 |
慢 SQL/慢请求治理 | 慢日志数量庞大、无人逐条分析 | Top N 慢 SQL/慢请求聚合 + 根因分析 + 优化建议 | 每周 1 次，查看慢查专项 |
风险事件排查 | 死锁/长事务/大表等隐患难发现 | DBbrain 诊断事件 + 风险评估 + 处理建议 | 每周 1 次，关注风险事件专项 |
锁与事务排查 | 锁等待/长事务阻塞业务 | MySQL 锁事务巡检 / PG 诊断事件中 lock/long_transaction | 按需触发，指定引擎和实例 |
大 Key/热 Key 治理 | Distributed Cache（兼容 Redis） 大 Key/热 Key 影响性能 | 大 Key 分类型阈值判定 + 热 Key 持续性分析 | 每周 1 次，查看大 Key/热 Key 专项 |
多引擎统一巡检 | MySQL/Distributed Cache（兼容 Redis）/MongoDB 混部、巡检碎片化 | 统一入口按引擎路由 + 标准化报告骨架 | 每周 1 次，分引擎各执行一次 |
实践建议
1. 按引擎维度组织巡检任务
由于各引擎巡检 Skill 独立执行，建议按引擎维度分别发起巡检。如果某引擎实例数量庞大（如超过 100 个），巡检 Skill 会自动分批处理，先完成前 100 个实例的完整巡检并输出报告，然后输出剩余未巡检实例列表，方便您发起后续批次。
注意：
单次巡检最多 100 个实例（MongoDB/Distributed Cache（兼容 Redis））或 500 个实例（MySQL/PostgreSQL）。超过上限时自动分批，不影响巡检质量。
2. 利用按需巡检，聚焦关注重点
各引擎巡检 Skill 均支持按需专项巡检，只执行用户指定的巡检项/模块，数据拉取层同步只获取相关数据，避免无效耗时。例如：
“只看慢 SQL” → 仅采集慢日志数据，不拉取空间分析等重数据
“只巡检锁和长事务” → 仅采集 DBbrain 诊断事件中的锁/事务类事件
“跳过空间分析”→ 全量巡检但跳过 TopSpaceTables 接口（耗时最长）
“只看大 Key/热 Key” → 仅采集 Distributed Cache（兼容 Redis） 大 Key/热 Key 数据
按需巡检仍会生成完整报告（含通用骨架），只是专项章节只覆盖启用项。
3. 利用历史风险追踪，形成连续观测链
每次巡检不是孤立快照，而是连续观测链。巡检 Skill 通过风险登记簿（risk_register.json）持久化所有活跃风险，每次巡检时自动与上次对比，标记每条风险的状态变化：
新增风险：本次首次发现
持续风险：上次存在且仍存在
恶化风险：严重程度升高
缓解风险：严重程度降低
复发风险：之前已恢复现又出现
已恢复：上次存在本次已恢复
建议连续 3 周以上的持续风险标记为高优先级，推动业务侧治理。
4. 定时任务配合 IM 推送，实现无人值守巡检
对于日常巡检场景，推荐创建定时任务并配置 IM 推送，上班后直接在 IM 群查看报告。
操作示例（MySQL 周度巡检）
步骤一：前置准备
下表列出了开始本实践前需满足的条件：
条件 | 说明 |
腾讯云账号 | 已完成实名认证。 |
腾讯云数据库 AI 服务 | |
数据库实例 | 至少已创建一个云数据库 MySQL（CDB）实例，且实例处于运行状态。 |
CAM 权限 | 实例绑定的用户角色具备对应数据库产品的只读、云监控只读、DBbrain 只读权限。 |
步骤二：发起巡检
方式一（推荐）：定时任务原生 Webhook 投递
1. 在目标 IM 平台创建群机器人并获取 Webhook 地址。企业微信、飞书、钉钉及自有 IM 同理，准备好可接收 HTTP POST 请求的 Webhook 地址即可。
2. 登录 DatabaseClaw 控制台。
3. 在左侧导航栏选择 DatabaseClaw > 实例管理，单击目标实例卡片进入对话页面。
4. 在对话页面顶部工具栏，单击定时任务。
5. 在右侧弹框上方单击创建任务。
6. 根据页面提示配置定时任务。创建时将结果投递设置为 Webhook，并填写 Webhook 地址。
「执行内容」填写内容参考：（可以根据实际需求调整概览信息格式）
对MySQL广州地域所有实例进行巡检，按照以下格式推送巡检概览信息：**【MySQL数据库健康巡检】{{date}}****报告地址**：[查看完整报告]({{cos链接}})，使用 markdown 链接格式**实例总数**：{{total_instances}}**健康分布**：🚨 紧急 {实例数}｜ ⚠️ 警告 {实例数}｜ ✅ 正常 {实例数}}**新增风险**：{{new_risks}}**巡检结论****总结**：简要总结本次巡检结果，关键数据要进行高亮显示**趋势**：简要总结巡检趋势分析（与上个周期的巡检情况比对）**紧急风险P0**每个风险仅保留一行格式：序号. **实例ID** — 核心现象，关键证据/趋势只保留最重要的 1~2 个指标数字优先保留“持续未恢复 / 持续上升 / 新增 / 已改善”这类状态词避免输出“现象/证据/建议”多行结构，除非只有 1 条 P0 且需要强调
方式二：对话发起单次巡检
1. 登录 数据库 AI 服务控制台。
2. 在左侧导航栏选择 DatabaseClaw > 实例管理，单击目标实例卡片进入对话页面。
3. 在对话窗口中发送巡检指令，例如：
1. MySQL 周度巡检帮我做一次 MySQL 周度巡检，覆盖广州地域所有实例2. MySQL 慢日志分析帮我做一次 MySQL 慢SQL周度巡检，覆盖广州地域所有实例
说明：
发送模糊触发词（如“帮我巡检数据库”）时，AI 会反问确认产品类型、实例 ID 和任务类型。如果消息中已包含明确的实例 ID 或地域信息，AI 会直接进入回显确认流程。
4. AI 会自动回显巡检任务配置，包括巡检引擎、地域范围、巡检项、时间窗口和输出产物。确认无误后，AI 自动开始执行巡检。
说明：
巡检过程全自动执行：实例发现 → 监控指标并发采集 → DBbrain 诊断数据采集 → 慢 SQL 采集 → 统计分析与异常检测 → AI 分章节生成报告 → COS 上传。每个阶段有实时进度输出，全程无需人工介入。实例数量越多，采集和 AI 分析耗时越长。
步骤三：查看巡检报告
方式一：IM 渠道查看
巡检完成后，DatabaseClaw 将推送巡检概览信息与完整的报告 COS 下载链接至 IM 渠道。点击下载链接即可获取完整的 Markdown 格式巡检报告。
方式二：控制台对话窗口
巡检完成后，AI 会在对话窗口输出巡检结果摘要和 COS 下载链接。点击下载链接即可获取完整的 Markdown 格式巡检报告。
详细报告内容结构如下：
章节 | 内容 |
本周总体结论 | 3-5 句概述，含 P0/P1/P2 风险数量 |
综合风险汇总 | 全局风险表，含风险状态/优先级/关键证据/当前影响/建议动作/建议完成时间 |
实例健康总览 | 健康分布统计 + 仅列异常实例（正常实例不逐行展示） |
数据来源和采集状态 | 各数据源成功/失败/空结果 + 完整性说明 |
专项分析 | 按引擎不同的巡检项/巡检专项进行分析总结 |
历史风险追踪 | 与上次巡检对比概述 + 历史遗留问题 + 已恢复问题 |
周度结论 | 整体评估 + 实例汇总表 + 下周关注重点 |
数据缺口 | 指标拉取失败记录（仅当有失败时才写） |
说明：
报告中只展示超过阈值的异常实例，未超标实例一律不展示。如某专项所有实例均正常，输出一行汇总说明即可。
各数据库巡检能力一览
MySQL 巡检项说明
巡检项 | 关注内容 |
资源趋势 | CPU/内存/磁盘/连接数/QPS/TPS 等关键水位和近期趋势 |
DBbrain 诊断事件 | 死锁、长事务、大表、自增键耗尽、主从切换等 5 类诊断事件 |
慢查询治理 | Top 慢 SQL 模板聚合 + 样例（库/User/完整 SQL），便于优化业务 SQL |
锁事务 | 锁等待、死锁、长事务、未提交事务详情 |
空间和大表 | 实例 Top 大表，识别空间增长风险（仅主实例） |
复制延迟 | 主从/只读复制延迟趋势 |
DDL 对象规范 | DDL 操作合规性检查 |
自增键风险 | 自增键耗尽风险评估 |
历史复盘 | 与上次巡检对比，追踪风险状态变化 |
Distributed Cache（兼容 Redis） 巡检项说明
巡检专项 | 关注内容 |
资源用量与内存风险 | CPU/内存峰值、驱逐 Key、淘汰策略与内存联合风险 |
应用吞吐量分析 | 入/出带宽利用率、连接利用率 |
命令请求综合分析 | 慢查询排行与明细、错误命令分析 |
高危命令分析 | KEYS/FLUSHALL/EVAL 等高危命令审计 |
大 Key/热 Key 分析 | 大 Key 检测（分类型阈值判定）、热 Key 访问频率与分布 |
架构风险评估 | 淘汰策略风险、标准版架构风险等 |
历史风险追踪 | 与上次巡检对比，追踪风险状态变化 |
MongoDB 巡检项说明
巡检专项 | 关注内容 |
基础资源风险 | Mongod/Mongos CPU/内存、集群/副本集磁盘、网络流量 |
连接与会话风险 | 连接使用率、连接突增 |
读写性能与慢请求 | 100ms+ 慢请求数量趋势、慢请求明细（namespace/操作类型/扫描方式） |
WiredTiger 存储引擎 | Cache 使用率/命中率/脏页比例 |
集群高可用 | 主从复制延迟、Oplog 保存时间 |
分片均衡与错误日志 | 分片磁盘倾斜、ERROR/FATAL 错误日志分析 |
历史风险追踪 | 与上次巡检对比，追踪风险状态变化 |
PostgreSQL 巡检项说明
巡检项 | 关注内容 |
综合指标和趋势 | CPU/内存/磁盘/连接数/缓存命中率等 9 个探针指标水位和趋势 |
DBbrain 诊断事件 | 锁等待、长事务、bloat、xid wraparound、复制延迟等诊断事件 |
慢 SQL 治理 | Top 慢 SQL 模板聚合 + 样例（库/User/完整 SQL） |
空间和大表 | 实例 Top 大表，识别空间增长风险（仅主实例） |
常见问题
Q1：巡检报告中部分实例的某些指标显示 N/A 或数据缺失？
巡检报告对数据缺失会显式标注 N/A 或在「数据缺口」章节说明，而非默认为正常。常见原因：
该实例为新创建实例，近 7 天内监控数据不完整。
该实例为只读实例（RO），部分 DBbrain 诊断接口（如空间分析）仅支持主实例。
该实例的 DBbrain 服务未开通或已过期。
该地域的云监控数据存在采集延迟。
API 调用失败（鉴权/超时/限流），会在「数据缺口」章节列出具体 RequestId 供溯源。
Q2：巡检耗时较长，如何优化？
优化建议：
缩小巡检范围：指定地域或实例 ID，避免全地域扫描。
按需巡检：只执行关注的巡检项，跳过耗时最长的项（如 MySQL/PG 的空间分析）。
分批巡检：实例数量超过 100 个时，巡检 Skill 会自动分批处理。
使用定时任务：在业务低峰期（如凌晨）执行定时巡检。
Q3：不同引擎可以一起巡检吗？
可以。统一入口 Skill 会根据实例 ID 前缀自动路由到对应引擎的巡检 Skill。如果您一次提供多个产品的实例，AI 会按产品和任务类型拆分为多个巡检任务，不混用规则和产物。每个引擎生成独立的巡检报告。
Q4：定时巡检任务创建失败怎么办？
常见失败原因及排查：
CAM 权限不足：创建定时任务需具备 tdai:CreateClawCron 权限。请联系管理员授权。
Cron 表达式不合法：请使用标准 5 字段格式（分 时 日 月 周），如 0 2 * * 1 表示每周一凌晨 2 点。
