Bonree ONE Sage AI运维智能体工作台是博睿数据基于可观测平台打造的智能体运维中枢，它将专家调优经验沉淀为结构化分析流程，让异常SQL诊断从“人工猜”走向“AI证”。
一、为什么“能跑但很慢”的SQL比报错更让运维头疼？
在生产环境里，最让人头疼的往往不是一眼能看出的报错，而是那些“能跑、但很慢”的 SQL。它们平时不声不响，一旦遇上高频调用或数据量增长，就会悄悄拖慢整条接口链路。
下面是一条真实的慢查询：一段带 LEFT JOIN 的多表统计 SQL，单次执行 0.605 秒，看似不长，但在被反复调用的场景下已经成了明显的性能瓶颈。过去定位这类问题，要靠工程师手动翻执行计划、逐行猜测原因，既费时又高度依赖个人经验。这一次，我们把它交给了 Bonree ONE 的 Sage AI。
二、Sage AI如何将模糊的慢查询转化为结构化诊断？
Sage AI的结构化分析引擎不依赖人工逐行猜测，而是通过语法语义检查、规则命中、根因假设、修复建议四步闭环，产出可验证的优化方案。
Sage AI给出的不是一句笼统的“建议加索引”，而是一套结构化的分析过程。
● 第一步是语法与语义检查，它发现 WHERE 条件里对右表 tiu.username 做了 NOT IN 过滤——这一步很关键：它意味着原本写成 LEFT JOIN 的左连接，实际语义已经退化成 INNER JOIN，左连接保留空行的开销完全白费。
● 第二步是规则命中清单，Sage AI逐条比对内置优化规则并标注证据等级，其中 AP-305 精准指向上面这个 JOIN 语义问题，AP-302 则指出参与 JOIN 的列缺少索引。
● 第三步，它基于这些证据给出根因假设；第四步，输出两条可直接落地的修复建议：P0 级，把 LEFT JOIN 改成 INNER JOIN，消除语义歧义；P1 级，为 t_iam_session_time 表的 login_time、user_id 建立联合索引，避免全表扫描。每条建议都附带预期收益、成本与回归风险，改不改、风险多大，一目了然。
三、 追加执行计划和DDL后，分析如何从“推断”升级为“论证”？
追加EXPLAIN执行计划与DDL建表语句后，Sage AI的分析依据从规则推断跃升为真实执行路径的硬证据，使优化建议的置信度达到可落地级别。
想分析得更深？再追加执行计划和 DDL。上面的判断主要基于规则和指标。如果想把根因坐实，还可以给 Sage AI 追加两样东西：SQL 的执行计划（EXPLAIN）和相关表的建表语句（DDL）。有了执行计划，Sage AI 能看清数据库到底走了哪条路——是全表扫描（type=ALL）还是命中了索引、预计扫描多少行、有没有产生临时表或文件排序；
有了 DDL，它能核对字段类型、已有索引和数据量级，判断建议的联合索引会不会因为字段顺序或选择性不佳而失效。把这两份信息喂进来，分析就从“基于规则的推断”升级为“基于真实执行路径的论证”，给出的优化建议也更有针对性、更能放心落地。
四、 实际动手改造后，效果究竟有多惊人？
遵循Sage AI的P0/P1建议进行改造，查询性能提升60倍，充分验证了结构化分析在AI可观测场景下的实战价值。
最后，我们照着建议动手改了 SQL：先改写 JOIN 语义、补上索引，又进一步把派生表先聚合再 JOIN，减少中间结果膨胀。改完重新执行，原来 0.605 秒的查询降到了 0.01 秒，提升约 60 倍。
五、 总结：Sage AI运维智能体工作台如何让每位工程师都成为DBA？
Bonree ONE Sage AI运维智能体工作台的核心价值在于将SQL调优从“专家手艺”转化为“平台能力”，在智能体工作台内实现诊断、建议、验证的闭环。
回头看整个过程，没有人去翻执行计划、逐行猜原因。Sage AI把“为什么慢、该改哪里、改完有什么风险”一次性讲清楚，工程师只需要做判断和验证。
对于每天要面对成百上千条 SQL 的团队来说，这意味着把原本依赖个别专家、难以复制的调优经验，沉淀成了平台随手可用的能力——让每一位工程师，都能像资深 DBA 一样读懂并修复异常 SQL。
Last Updated: 2026年6月16日 · Bonree ONE 4.0.0.7
版本说明：本文基于 Bonree ONE 4.0.0.7 版本（2026年6月16日更新）撰写。该版本包含 Sage AI智能体运维工作台、APM、RUM、SDK、Alert、Analysis、Event、CMDB、ETL、IAM 等能力模块的同步升级。
