一条业务请求连接 MySQL 很慢，问题可能不是网络，而是连接和线程已经堆起来了。
一笔订单更新卡住了，问题可能不是应用代码，而是数据库里有事务正在持锁。
一次备份失败了，问题可能不是数据库不可用，而是 KubeBlocks 备份策略配置出了问题。
当数据库运行在 Kubernetes 上，运维链路会变得更长。一次 MySQL 问题，可能同时涉及数据库内部状态、KubeBlocks Cluster、Pod 生命周期、PVC 存储、备份对象、复制关系和云上权限。DBA 需要理解数据库，平台运维需要理解 Kubernetes，业务团队还要判断问题是否影响应用请求。云原生带来了弹性、自动化和标准化，也把排障门槛进一步抬高了。
为了解决这类云原生数据库运维问题，KubeBlocks 企业版推出了智能诊断 Agent 功能。它面向数据库与云原生运维团队，把集群上下文、诊断证据、报告产物和安全确认流程组织成一次可追踪的智能诊断体验。
KubeBlocks AI Agent 深度集成 KubeBlocks 企业版的数据库可观测基础设施和专业 DBA 团队经验，内置数十种面向 KubeBlocks Addon 的专业诊断 SKILL。它能够先识别诊断目标，再围绕目标收集证据，最后生成诊断结论、影响判断和下一步建议，而不是停留在泛泛的聊天问答。
从交互上来看，一次诊断通常从一个自然语言问题开始，AI Agent 会帮助用户完成上下文理解、证据收集、报告生成和下一步建议：
- 进入集群页面：自动携带当前组织、集群和时间范围，减少重复配置。
- 提出诊断问题：支持自然语言，用最简单的描述开始一次复杂诊断。
- 规划诊断路径：识别健康检查、日志分析、性能报告、配置核查等任务类型。
- 收集现场证据：读取必要的集群状态、事件、日志、指标、数据库状态和报告文件。
- 生成诊断结论：输出原因分析、影响范围、风险等级和建议动作。
- 交付可追踪结果：报告可浏览或下载，关键过程保留工具确认和审计线索。
我们以 MySQL Top 10 热点问题为例，展示 KubeBlocks AI Agent 如何把 DBA 常用的排障路径、KubeBlocks 运维对象和真实集群证据组织成一条完整诊断链路：从用户的一句话问题出发，自动判断应该检查连接、事务、锁、执行计划，还是实例、存储、备份等云原生对象，并把过程和结论沉淀为可复盘的诊断记录。
为了让案例更贴近实际运维场景，我们把 MySQL 热点问题分成两类：
- MySQL 内核类诊断：连接、事务、锁、死锁、执行计划和 I/O 等数据库内部问题；
- KubeBlocks / Kubernetes 相关诊断：实例状态、存储、备份等云原生运维对象问题。
下面先看 MySQL 内核相关问题。
一、MySQL 内核类问题诊断
1. 连接数异常：应用连接 MySQL 变慢
用户问题
"应用反馈连接 MySQL 很慢，怀疑数据库连接数或线程堆积，帮我看看当前连接是否异常。"
现场如何构造
我们启动一批受控 MySQL 客户端连接，让它们保持活跃等待，形成连接和线程堆积。该现场控制在数据库连接上限以下，用来模拟"应用侧感觉连接慢、数据库侧连接/线程压力升高"的场景。
AI Agent 如何诊断
AI Agent 从自然语言问题出发，检查连接数、线程状态和 processlist，识别出当前活跃连接与线程堆积，并把问题归因到特定 workload。
用户并不需要指定检查命令，只要描述"连接 MySQL 很慢"这样的业务现象。AI Agent 会把问题拆成连接数、线程状态和会话来源几个检查方向。
关键推理里，AI Agent 对比当前连接和线程状态，发现大量会话集中在同一类等待场景中，说明这不是单个 SQL 慢，而是连接与线程层面的堆积风险。
诊断结论把问题收敛为连接与线程堆积，并指出异常会话的来源和处理方向。这个判断是成立的：AI Agent 没有停留在"建议检查连接池"的泛泛建议，而是用真实会话状态支撑结论，专业性体现在能把用户的"连接慢"翻译成数据库侧可定位的连接压力问题。
2. 长事务异常：历史版本清不掉
用户问题
"数据库最近好像有历史版本一直清不掉，帮我看看是不是有长事务或者 undo 堆积。"
现场如何构造
我们在独立测试表上保持一个长事务不提交，同时制造少量更新，让 InnoDB history list 出现增长。这个现场模拟线上常见的"长事务阻塞 purge，历史版本无法及时回收"问题。
AI Agent 如何诊断
AI Agent 检查 InnoDB 状态和事务信息，识别长事务与 history list 增长之间的关系，并给出终止异常事务、优化事务边界的建议。
这个提问更接近 DBA 日常会收到的"历史版本清不掉"类问题，用户不一定知道背后是 undo、purge 还是事务边界。
关键推理里，AI Agent 把长时间未提交事务与 history list 增长联系起来，说明风险来自事务长期持有快照，导致旧版本无法及时回收。
诊断结论明确指出存在长事务和 history list 增长风险，并建议优先确认长事务来源、缩短事务边界、避免长期持有快照。这个结论符合 InnoDB 的工作机制：长事务不一定马上造成业务报错，但会影响 purge 和版本回收，AI Agent 对风险性质和处理优先级的判断是专业的。
3. 锁等待：从行锁到用户级内部锁
用户问题
"订单状态更新一直卡住，帮我看看数据库里是不是有锁等待。"
案例 A：InnoDB 行锁等待
现场如何构造
我们在示例订单表中选择一条测试订单记录，用一个受控事务持有这行数据的锁；再发起另一个更新请求，让它等待同一行锁。这个现场模拟的是线上常见的"事务未提交导致写入阻塞"。
AI Agent 如何诊断
AI Agent 检查当前事务和锁等待信息，识别出持锁会话和等待会话，判断为未提交事务导致的行锁等待。
在用户视角里，问题只是"订单更新卡住"。AI Agent 需要把这个现象翻译成数据库内部的事务和锁等待关系。
关键推理里，AI Agent 找到了等待会话和阻塞会话的对应关系，判断写入卡住来自行锁等待，而不是数据库整体不可用。
诊断结论把"订单更新卡住"定位为行锁等待，并给出了持锁会话、等待会话以及谨慎处理建议。这个判断准确地还原了阻塞链路：不是简单说"有锁"，而是说明谁在阻塞、谁在等待、为什么写入会卡住，符合 DBA 排查锁等待时的专业路径。
案例 B：用户级 advisory lock 等待
"应用里有一条数据库请求一直卡住，帮我看看 MySQL 里面是不是有锁等待。"
现场如何构造
我们使用 MySQL 用户级 advisory lock 构造一个持锁会话和一个等待会话。它不是 InnoDB 行锁，也不是元数据锁，但真实应用中如果使用这类锁，同样可能导致请求长时间等待。
AI Agent 如何诊断
AI Agent 通过 processlist 和锁函数识别持锁会话和等待会话，同时排除 InnoDB 行锁和元数据锁，把问题归类为用户级锁等待。
这个问题的难点在于，同样表现为"请求卡住"，背后可能是行锁、元数据锁，也可能是应用自己使用的用户级锁。
关键推理里，AI Agent 通过会话状态和锁函数信息区分出用户级锁等待，避免把它误判为 InnoDB 行锁或 MDL。
诊断结论将问题归类为用户级 advisory lock 等待，而不是 InnoDB 行锁或 MDL。这个区分很关键：不同锁类型对应不同处置方式，AI Agent 能识别锁的类别，说明它不是只按关键词判断"锁等待"，而是在结合会话和锁函数证据做专业诊断。
4. MDL 元数据锁：表结构变更卡住
用户问题
"表结构变更一直没有完成，应用发布卡住了，帮我看看 MySQL 里是不是有元数据锁等待。"
现场如何构造
我们在测试表上保持一个表级读锁，再发起一次 DDL 变更，使 DDL 等待元数据锁。这个现场模拟线上发布过程中常见的"表结构变更被长查询或事务阻塞"。
AI Agent 如何诊断
AI Agent 从 processlist 中识别到 Waiting for table metadata lock，定位出持锁会话和等待中的 DDL。
在发布或变更窗口里，DDL 卡住往往比普通慢 SQL 更紧急，因为它可能影响后续发布流程。
关键推理里，AI Agent 捕捉到 Waiting for table metadata lock 这类关键等待状态，并把 DDL 卡住与元数据锁阻塞关联起来。
诊断结论确认 DDL 卡在元数据锁等待上，并给出先确认阻塞会话、再决定是否终止或调整变更窗口的建议。这个结论专业且可执行：它没有把 MDL 混同为普通行锁，而是围绕发布变更场景给出更谨慎的处置顺序。
5. InnoDB 死锁：订单更新失败
用户问题
"刚才订单更新失败，应用日志里出现 Deadlock found when trying to get lock，帮我定位 MySQL 最近一次死锁原因。"
现场如何构造
我们在测试表上打开两个事务，让它们以相反顺序更新两行数据，从而触发一次 InnoDB 死锁。这个现场对应真实业务中常见的并发更新顺序不一致问题。
AI Agent 如何诊断
AI Agent 检查 InnoDB 状态中的最近死锁信息，识别出两个事务的冲突顺序，并给出固定更新顺序、失败后重试、缩短事务的建议。
死锁通常只在业务日志里留下一个错误，真正的原因需要回到数据库内部还原两个事务的冲突顺序。
关键推理里，AI Agent 从最近一次死锁信息中还原冲突路径，识别两个事务如何互相等待，从而给出固定更新顺序和重试策略。
诊断结论说明最近一次死锁来自两个事务以不同顺序更新资源，并建议固定更新顺序、缩短事务、失败后重试。这个判断符合 InnoDB 死锁分析方法：AI Agent 能把底层死锁文本转成业务研发也能理解的冲突路径和改造建议。
6. 慢 SQL 诊断：卖家订单状态报表查询慢
用户问题
apecloud_demo 里按卖家统计订单状态的报表查询很慢，希望判断是不是 SQL 或索引设计有问题。
现场如何构造
我们使用 apecloud_demo 示例业务库中的订单、订单明细和卖家信息表构造一个典型报表查询：按卖家统计不同订单状态的数量。这个查询涉及 10 万级订单和订单明细数据，如果关键业务字段缺少合适索引，优化器就可能选择全表扫描，并在分组阶段产生临时表和文件排序。
执行的具体查询为：
sql
SELECT s.seller_id, o.order_status, COUNT(*) AS cnt
FROM sellers s
JOIN order_items oi ON s.seller_id = oi.seller_id
JOIN orders o ON oi.order_id = o.order_id
GROUP BY s.seller_id, o.order_status
ORDER BY s.seller_id, o.order_status;这个场景贴近真实业务：用户看到的是"报表慢"，但真正需要定位的是表数据量、索引覆盖、执行计划、临时表和排序之间的关系。
AI Agent 如何诊断
AI Agent 从自然语言问题出发，检查表规模、已有索引和 EXPLAIN 执行计划，判断慢查询根因是否来自全表扫描和缺失索引，而不是直接给出"加机器"或"重启数据库"这类泛化建议。
这个问题没有直接给出 SQL 或期望结论，AI Agent 需要自己理解"按卖家统计订单状态"这个业务需求，并将它转换成可验证的 SQL、索引和执行计划检查路径。
关键推理里，AI Agent 读取 EXPLAIN 后发现查询从 orders 表开始全表扫描，扫描约 89,596 行，并在 GROUP BY 阶段出现 Using temporary; Using filesort。它进一步指出 order_items.seller_id 缺少索引，导致无法从卖家维度高效定位订单明细。
诊断结论把问题归因到 orders 和 order_items 缺少关键业务索引：orders 只有主键，order_items 只有 (order_id, order_item_id) 主键，无法支撑按卖家和订单状态聚合的报表查询。建议新增 order_items.seller_id 和 orders.order_status 相关索引，并在加索引后重新用 EXPLAIN 验证扫描行数和执行路径。这是一个典型的慢 SQL 诊断闭环：从症状到执行计划，再到索引建议和后续验证。
在用户明确确认需要继续处理后，AI Agent 还可以把诊断建议推进到后续优化验证：先确认当前索引状态，再执行索引优化，并重新检查执行计划。这个过程的关键不是"直接改库"，而是把变更动作放在用户确认和可复核证据之后，让优化前后的差异能够被看见。
后续处理结果显示，新增 order_items.seller_id 索引后，order_items 的访问方式从 ALL 全表扫描变为 ref 索引访问，扫描行数从约 111,757 行下降到 3 行。这个对比让优化效果非常直观：AI Agent 不只是给出"建议加索引"，还能够在授权后完成验证闭环，证明建议确实改善了执行路径。
7. I/O 压力：临时表磁盘溢出
用户问题
业务查询出现明显延迟，怀疑数据库存在磁盘 I/O 压力，希望判断压力来源和影响范围。
现场如何构造
我们构造的是"查询中间结果落盘"这一类 I/O 压力现场：让业务查询产生较多临时表，并观察 MySQL 实例的磁盘临时表比例、fsync、pending fsync、容量和复制延迟等指标。这里关注的不是单条 SQL 的执行计划优化，而是当临时表落到磁盘后，AI Agent 能否判断压力来源和影响范围。
AI Agent 如何诊断
AI Agent 没有把问题简单归因于"磁盘慢"，而是先检查可用的 I/O 指标，再对比两个 MySQL 实例的 fsync、pending fsync、磁盘临时表、CPU、内存、连接数和复制延迟等数据。
这类问题很适合体现 AI Agent 的"如实诊断"能力：它会先确认 I/O 压力是否真实存在，再判断压力来自 InnoDB 日志/数据刷盘、存储空间，还是查询产生的临时表落盘。
关键推理里，AI Agent 先枚举可用的 I/O 相关指标，然后继续查询两个 MySQL Pod 的 fsync、pending fsync、临时表和容量数据。这一步很重要：它不是凭经验直接给建议，而是在确认"哪些指标能证明 I/O 压力"。
诊断结论把问题收敛到 mysql-1 上较高的磁盘临时表比例：当前 InnoDB 数据/日志 fsync 速率正常、pending fsync 为 0、存储空间使用率较低，因此主要压力不是底层存储已满或 fsync 堆积，而是查询中间结果落盘带来的额外 I/O。AI Agent 同时提示 mysql-0 近期重建和复制延迟需要关注，说明它没有只看单一指标，而是在把 I/O、实例状态和复制状态放在一起判断。
二、KubeBlocks / Kubernetes 相关诊断
数据库运行在 K8s 上后，很多问题已经不再只发生在数据库内部。实例重建、PVC 空间、备份对象、KubeBlocks 运维资源都会影响数据库可用性。下面这些案例体现的是 AI Agent 对云原生数据库运维对象的理解能力。
8. 实例异常：识别实例恢复状态
用户问题
用户看到 MySQL 实例出现异常恢复痕迹，希望确认哪个实例发生过重启或重建。
现场如何构造
我们对一个 secondary 实例做受控重建演练，由 KubeBlocks 负责拉起同名 Pod 并恢复复制状态。这个场景用于验证 AI Agent 是否能结合 Kubernetes 状态、Pod 生命周期和数据库角色判断异常实例。
AI Agent 如何诊断
AI Agent 通过集群和 Pod 状态识别出近期被重建的实例，并确认复制恢复正常，没有发现更大范围的异常信号。
用户看到的是"实例好像异常过"，AI Agent 需要把这个现象和 Pod 生命周期、角色、复制状态一起串起来看。
关键推理里，AI Agent 结合实例角色、Pod 状态和恢复过程判断当前实例已经恢复，避免把历史恢复痕迹误报成正在发生的故障。
诊断结论确认实例存在恢复痕迹，但当前 Pod 和复制状态已经恢复正常，没有发现持续故障。这个判断是合理的：AI Agent 没有把历史重建痕迹误报为当前故障，而是结合 KubeBlocks 集群状态、Pod 生命周期和 MySQL 角色给出"已恢复、需继续观察"的结论。
9. 存储异常：定位单实例磁盘压力
用户问题
"MySQL 集群存储空间好像有告警，帮我看看是不是哪个实例磁盘快满了。"
现场如何构造
我们在一个 MySQL 实例的数据目录中制造明显的空间占用，让该实例磁盘使用率升高到告警水位。这个现场更接近"某个实例被异常文件或临时数据占满"的真实运维风险。
AI Agent 如何诊断
AI Agent 对比不同 MySQL 实例的磁盘使用情况，发现只有一个实例的 /var/lib/mysql 使用率明显升高；继续检查后，它区分了真实 MySQL 数据目录和异常大文件。
在存储异常诊断中，AI Agent 不是只看集群总体存储水位，而是进一步比较不同实例的数据目录使用情况，定位异常空间占用来自哪里。
诊断结论定位到单实例目录空间异常升高，并提示先确认异常大文件来源，再决定清理、归档或扩容。这个建议是正确且安全的：AI Agent 没有直接建议删除文件，而是把风险、影响范围和处置顺序说清楚，符合生产环境存储问题的处理原则。
10. 备份异常：识别备份策略问题
用户问题
"MySQL 集群最近一次备份是不是失败了？帮我看看原因。"
现场如何构造
我们创建一次受控的手动备份记录，让它引用一个不存在的备份策略。备份控制器会将该任务标记为失败，并给出策略不存在的错误。这个现场用于模拟备份配置不一致导致的失败。
AI Agent 如何诊断
AI Agent 检查最近的备份对象和状态，确认手动备份失败，并定位到失败原因是引用了缺失的 BackupPolicy。
备份失败属于典型的 KubeBlocks 运维流程问题。AI Agent 要看的不是单个数据库进程，而是备份对象、策略引用和控制器返回的错误。
诊断结论确认最近一次手动备份失败，失败原因是引用的 BackupPolicy 不存在。这个判断准确命中了 KubeBlocks 备份链路中的配置问题：AI Agent 不只是检查数据库是否 Running，而是进一步理解备份对象、策略引用和控制器错误，给出了可直接修复的方向。
三、不是黑盒聊天，而是可审计的 AI 运维
做运维场景的 AI，不能只追求"像专家一样回答"。企业用户还关心另一个问题：AI 到底做了什么？有没有越权？检查过哪些对象？失败在哪里？结论能不能复盘？
这也是 KubeBlocks AI Agent 与普通聊天机器人的关键区别：诊断过程可以被记录、查看和审计。
对于可能访问集群或数据库的检查动作，系统会保留工具请求记录，并在需要时进行人工确认。用户可以知道 AI Agent 想检查什么、为什么检查，以及这一步是否被允许。
在涉及敏感检查或可能影响集群状态的动作前，AI Agent 会把将要执行的操作展示给用户确认，而不是在后台无感执行。对企业运维来说，这意味着 AI 可以参与诊断流程，但关键动作仍然保留在人可以理解、可以授权、可以审计的路径内。
诊断结束后，Diagnosis completed 详情可以帮助用户复盘本轮诊断状态，确认本轮检查已经完成，而不是停留在"AI 正在思考"的不确定状态。
如果某个工具调用失败，失败原因也会被保留下来。这样用户可以区分是权限不足、对象不存在、命令失败，还是环境本身不可用。
这套审计能力让 AI Agent 更适合进入真实生产运维流程：它不是绕过权限直接执行动作，而是在既有权限、确认和审计边界内完成诊断。
结语
数据库运维的核心不是"回答得像专家"，而是能不能基于真实证据，帮助用户安全、可复盘地完成排障。KubeBlocks AI Agent 的产品价值，也体现在这三点上：
- 更快定位问题：用户只需要描述现象，AI Agent 会识别诊断目标，自动串起数据库状态、Kubernetes 资源、KubeBlocks 运维对象和监控证据，缩短从"发现异常"到"定位原因"的路径。
- 更安全地辅助执行：涉及工具检查和潜在敏感动作时，系统保留确认、权限和审计边界，让 AI 参与运维流程，但不绕过人的授权和企业既有治理要求。
- 更完整的交付物：诊断过程、关键证据、最终结论、失败原因和报告产物都可以被追踪，让一次 AI 诊断不只是临时聊天，而是可以复盘、可以沉淀、可以交付的运维结果。
从这次 MySQL Top 10 实战可以看到，KubeBlocks AI Agent 已经能够覆盖连接、事务、锁、死锁、执行计划、实例、存储、备份等典型场景。此外，KubeBlocks AI Agent 也已支持 PostgreSQL、MongoDB、Redis、Oracle、DamengDB 等更多数据库引擎的智能诊断，正在形成面向多数据库的统一智能运维体验。
在 AI 时代，运行在 Kubernetes 上的数据库运维不应该只是把更多对象、更多指标和更多命令堆给用户。真正有价值的智能化，是把复杂的云原生上下文、数据库专家经验和现场证据组织起来，让不同角色都能更快进入同一个问题现场。
对 DBA 来说，这套能力不是替代专业判断，而是把重复的取证、关联分析和报告整理交给 AI Agent，让专家把精力放在关键决策和复杂处置上。对业务用户和平台运维来说，它降低了描述问题和发起排障的门槛：不需要先知道该查哪些命令，也能从一个自然语言问题开始，得到有证据、有边界、有建议的诊断结果。这也是 KubeBlocks AI Agent 的核心意义：让数据库运维从"依赖少数专家手工排查"，逐步走向"人人都能发起、专家可以复核、过程可以追踪"的智能化协作。
你还希望看到 KubeBlocks AI Agent 诊断哪些数据库引擎、哪些运维场景？也欢迎把你关心的 AI 数据库运维问题留在评论区，我们会持续分享更多实战案例。
了解 KubeBlocks 企业版：kubeblocks.com/products/ku...