DBbrain

DBbrain（数据库智能管家）是腾讯云推出的数据库运维诊断平台，官方产品页在 cloud.tencent.com/product/cb。它的职责很具体：读数据库运行过程中产生的数据——慢查询日志、执行计划、统计信息、会话与审计日志——然后回答「这条 SQL 为什么慢」「这次异常是谁干的」。

它属于 AI编程 分类，但做的不是代码。这一点在站内此前是空白的：code 分类原有 23 款，绝大部分作用于源码或应用层——写代码的 IDE 与助手（TRAE、通义灵码、腾讯CodeBuddy、Cursor 等）、审 PR 代码文本的 CodeRabbit、扫源码漏洞的 Semgrep、管接口契约的 Apifox、以及十款低代码建站平台。没有一款的输入是「数据库跑起来之后的运行数据」。

⭐ 它的边界要说准，这是它和站内已有工具最容易混淆的地方：

一个是扫源码、一个是查运行时，对象完全不同，可以并存——而且真实项目里经常同时需要。

AI 具体落在哪？ 按腾讯云官方文档（cloud.tencent.com/document/product/409/132356）的口径，它把 DBbrain 智能运维平台与 AI 大模型结合：自动采集慢查询日志，用 AI 模型分析执行计划，给出索引优化、SQL 改写、参数调整三类建议。更进一步有两个可直接调用的能力：

• tencentdb_ai 插件——可以在 SQL 会话内直接对慢查询做 AI 分析，不必反复切控制台
• tencentdb_index_advisor 扩展——智能索引推荐，除单条 SQL 的 advise_index 外还有 advise_index_workload，可对一段工作负载批量出建议

这块设计值得留意：它的产出不是一段解释文字，而是能直接落地的动作（加哪个索引、改写成什么形态、参数调到多少）。

⚠️ 一个如实说明：DBbrain 的产品页是 JS 渲染的短页面（正文仅 986 字节），功能事实取自腾讯云官方文档站的产品文档，而不是营销页。

• 大陆网络：可直接访问，腾讯云国内直连，官方文档站与控制台在国内可正常访问，无需自备国际网络
• 界面语言：原生简体中文，控制台与官方文档均为中文
• 注册：需腾讯云账号；面向已购买腾讯云数据库实例的用户，自建数据库可经 Agent 接入
• 付费：⚠️ 官网无公开价目表，不编具体金额。计费与所购云数据库实例规格及增值项相关，自建数据库接入的计费口径按当期文档确认
• 数据合规：数据在腾讯云侧处理，国内合规路径清晰；但数据库运行数据（慢查询、SQL 语句、审计日志）本身敏感，实例侧需按需开启采集并控制采集范围

• 慢 SQL 分析：按 SQL 模板聚合慢查询，记录执行次数、总耗时、扫描行数与返回行数，可按平均耗时或最大耗时排序定位问题语句
• AI 辅助慢 SQL 诊断：结合 DBbrain 智能运维平台与 AI 大模型，自动采集慢查询日志、用模型分析执行计划，输出索引优化、SQL 改写与参数调整建议
• tencentdb_ai 插件：可在 SQL 内直接对慢查询执行 AI 分析，把诊断能力放进数据库会话里，不必反复切控制台
• tencentdb_index_advisor 智能索引推荐：按单条 SQL 或整段工作负载批量给出索引建议，减少手工试索引的往返
• 执行计划可视化：把 EXPLAIN 结果以可缩放的图形方式呈现，锁等待、扫描行数、返回行数的横截面占比可视化
• 异常事件根因分析：对性能异常与健康检查事件做智能分析，定位到具体操作，给出资源配置与参数调优建议
• 审计日志分析：按 QPS 或慢查询数创建审计任务，回收后按 SQL 类型、主机、用户或 SQL 代码多维度交叉分析
• 数据库类型覆盖：MySQL、PostgreSQL、TDSQL-C 等腾讯云数据库，以及通过 Agent 接入的自建数据库
• 资源与配置建议：从 SQL 优化、索引与改写，到资源配置优化与参数微调，给出可执行的专家建议

第一步：确认能不能用上。 DBbrain 主要服务腾讯云上购买的数据库实例（MySQL、PostgreSQL、TDSQL-C 等）。自建数据库可以通过 Agent 接入，但支持面比云上实例窄，且慢日志分析这类功能需要实例侧先开启相应采集——先确认你的库是否已被采集，再谈后面的事。

第二步：从慢 SQL 分析入手。 登录 DBbrain 控制台，在左侧导航选「诊断优化」，选定数据库类型与实例，进入「慢 SQL 分析」。这一步会看到两个东西：慢查询数量与该实例 CPU 利用率的时间分布柱状图，以及按 SQL 模板聚合的慢查询列表（执行次数、总耗时、扫描行数、返回行数）。

排序时有一个官方特别提醒：按平均耗时或最大耗时排序，不要按总耗时排序——总耗时容易被执行次数多的语句拉高，把真正慢的那条挤下去。

第三步：用两类横切指标区分「慢的原因」。 官方的判断口径可以直接拿来用：

• 返回行数与扫描行数相同 → 大概率是全表扫描，通常是查询条件没走索引
• 扫描行数多而返回行数很少 → 产生了大量逻辑读与物理读，容易把 CPU 打满

这两类的解法完全不同：前者加索引，后者往往要改写查询或拆分。

第四步：看 AI 诊断。 点进某条 SQL 模板，右侧出具体分析与统计信息。开启 AI 诊断后可拿到由模型分析执行计划生成的报告。官方文档给了三个典型场景，可以当作判读模板：

• 缺索引：SELECT * FROM users WHERE email = ... 走了 Seq Scan（百万行表）→ 结论是 email 列没索引，建议建索引，执行时间可从秒级降到毫秒级
• 统计信息陈旧：执行计划选了错误的 JOIN 顺序 → 根因是 pg_statistic 的行数估算偏差超过百倍，跑 ANALYZE 更新统计信息即可
• 需要改写：NOT IN 子查询 → 建议改用 NOT EXISTS 以避开 NULL 语义问题并提升效率

注意第二类：统计信息过期时它也会给错方向。这说明 AI 建议的可信度依赖实例的统计数据质量，不是无条件正确。

第五步：批量拿索引建议。 需要给整段工作负载补索引时，用 tencentdb_index_advisor 的 advise_index_workload 传入一组 SQL，一次性拿到建议，比一条条试省事。

第六步：出事故时查根因与审计。 异常事件功能会做智能分析定位到具体操作，并给出 SQL 优化、资源配置与参数微调三类专家建议。开了数据库审计功能的实例还可以创建审计任务，回收后按 QPS 或慢查询数看视图，再按 SQL 类型、主机、用户或 SQL 代码交叉分析——这时它回答的是「那段时间是谁在跑什么」。

第七步（可选）：把 AI 放进排障现场。 结合 tencentdb_ai 插件，可以直接在 SQL 里调用 AI 分析：

```sql

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)

SELECT * FROM orders WHERE customer_id = 12345 AND order_date > '2026-01-01';

SELECT tencentdb_ai.chat_completions(

'hunyuan-xxx',

'Analyze the following execution plan, identify performance bottlenecks, and provide optimization suggestions:'

|| (SELECT query FROM pg_stat_statements WHERE queryid = $1)

);

```

官方提醒一个实操细节：生产环境取目标 SQL 用 queryid 精确匹配，不要用模糊 LIKE，避免命中无关查询。

优点

• 站内第一款「读数据库运行数据」的工具：code 分类此前 23 款全部作用于源码或应用层，没有一款看慢查询日志与执行计划
• AI 落点是可交付的诊断报告与优化建议，而不是聊天式问答——产出直接对应「加索引」「改写语句」「调参数」三类具体动作
• 索引推荐支持整段工作负载批量分析，比一条条手工试省事得多
• tencentdb_ai 插件把 AI 分析放进 SQL 会话内，排查时不用在控制台和客户端之间来回切
• 腾讯云国内直连，且对腾讯云自家数据库（TDSQL-C、TencentDB for PostgreSQL 等）适配路径最短
• 除慢 SQL 外还覆盖异常事件根因与审计日志分析，事故复盘时能直接调出当时的 SQL 分布

局限

• 它是运维诊断工具，不是数据库客户端——建表写业务 SQL 仍要回到你自己的客户端，DBbrain 负责的是「为什么慢」
• 强绑定云上数据库：走 Agent 接入的自建数据库支持面比云上实例窄，部分功能（如慢日志分析）需要实例侧先开启采集
• AI 建议基于执行计划与统计信息推理，统计信息过期时（ANALYZE 没跑）它会给错方向
• SQL 改写建议要人工判断语义是否等价，改错不会报错但结果会变
• 按云数据库实例规格与增值项计费，官网无公开价目表；数据库本身开销通常比这个诊断工具大得多
• 它是「事后诊断」——不能替代索引设计与分库分表这些事前工作
• 跨云与跨引擎的一致性有限，非腾讯云数据库的功能覆盖范围要按当期文档确认

场景一：接口突然变慢，先怀疑数据库。 打开慢 SQL 分析，看到慢查询数与 CPU 同时飙升。按平均耗时排序，最上面一条执行次数不高但单次耗时长。点进去看执行计划，是全表扫描。AI 诊断直接给出建索引建议。这类问题的排查路径在传统工具下要人工看慢日志、猜、试；它的价值在于把「猜」这一步省了。

场景二：CPU 被打满但看不出是哪条 SQL。 按官方口径，这时要看扫描行数与返回行数的比值而不是只看耗时：扫描行数巨大但返回很少的语句，是大量逻辑读与物理读在烧 CPU。锁定后再看是索引缺失还是语句本身写得差。

场景三：发版后怀疑数据库被拖慢。 创建审计任务，回收数据后按 SQL 代码维度看发版前后的分布对比，找出新增的慢查询来自哪个新接口。

场景四：接手一个没人维护的数据库。 对主要业务表的工作负载批量跑 advise_index_workload，一次性拿到索引建议清单。逐条评估后按收益排序实施，比从头梳理索引现状快得多。

场景五：判断该调规格还是该改代码。 异常事件给出的建议分三类（SQL 优化 / 资源配置 / 参数微调）——如果 SQL 侧几乎无优化空间而资源打满，那就是规格问题；如果单条语句就能吃掉大半资源，先改 SQL 再谈加配置。

场景六：边查边问，不用切控制台。 用 tencentdb_ai 插件在 psql 里直接分析当前这条慢查询，拿到建议后当场改。

同类还有商业数据库自带的诊断工具（如 Oracle 的诊断包、各云厂商的数据库监控），以及通用数据库客户端里的慢日志分析脚本。它们与 DBbrain 的差别主要在是否接入 AI 模型生成诊断结论、是否把索引推荐做成可批量调用的能力，以及是否与云上实例的运行数据打通。

⚠️ 官网无公开价目表，不编具体金额。计费与所购云数据库实例规格及增值项相关；自建数据库接入的计费口径按当期文档确认，以官网价格表为准

价格与档位可能随时调整，以上信息以官网为准。

• 线上突然变慢：先在慢 SQL 分析里按平均耗时排序锁定语句，再看 AI 诊断报告给的索引与改写建议
• 发版后数据库性能回退：用审计日志分析对比发版前后的 SQL 分布，找出新增的慢查询来源
• 接手一个陌生的数据库：按扫描行数与返回行数的横截面占比找出全表扫描类问题，批量拿索引建议
• 清理「看着像慢查询其实不是」的干扰项：返回行数多但耗时高的语句与扫描行数大但返回少的语句，问题来源完全不同
• 容量与配置评估：结合异常事件的资源配置建议，判断是该调规格还是该改 SQL
• 把 AI 放进排障现场：在 psql 或客户端里直接调用 tencentdb_ai 做单条慢查询分析，边查边问

以下工具与 DBbrain 在场景上有交集或重叠，可一并比较：