你有没有遇到过这种情况：应用突然反馈连不上MySQL了，业务订单更新卡住了，或者备份任务莫名其妙就失败了？
在传统架构里，查问题多半是个相对线性的过程。但到了云原生环境，事情就复杂了。一次MySQL的问题，可能同时牵扯到数据库内部的状态、KubeBlocks Cluster对象的配置、Pod的生命周期、PVC的存储状况、备份的策略，甚至还有云上的权限。
一条业务请求连接很慢，问题可能不在网络，而是连接和线程堆积了。一笔订单更新卡住，问题可能不是应用代码，而是数据库里有事务正拿着锁。一次备份失败，问题可能不是数据库不可用，而是KubeBlocks的备份策略配错了。DBA需要懂数据库，平台运维需要懂Kubernetes，业务团队还得判断问题到底影不影响自己。云原生带来了弹性、自动化和标准化，同时也把排障的门槛实实在在地抬高了。
正是为了解决这类云原生数据库的运维难题，KubeBlocks企业版推出了智能诊断Agent功能。它面向数据库与云原生运维团队，把集群上下文、诊断证据、报告产物和安全确认流程，组织成一次可追踪、可复盘的智能诊断体验。
这个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万级的订单和订单明细数据。如果关键业务字段缺少合适的索引，优化器就可能选择全表扫描，并在分组阶段产生临时表和文件排序。
执行的具体查询为：
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已经能够覆盖连接、事务、锁、死锁、执行计划、实例、存储、备份等典型场景。此外，它也已支持PostgreSQL、MongoDB、Redis、Oracle、DamengDB等更多数据库引擎的智能诊断，正在形成面向多数据库的统一智能运维体验。
在AI时代，运行在Kubernetes上的数据库运维不应该只是把更多的对象、更多的指标和更多的命令堆给用户。真正有价值的智能化，是把复杂的云原生上下文、数据库专家经验和现场证据组织起来，让不同角色都能更快地进入同一个问题现场。
对DBA来说，这套能力不是替代专业判断，而是把重复的取证、关联分析和报告整理交给AI Agent，让专家把精力集中在关键决策和复杂处置上。对业务用户和平台运维来说，它降低了描述问题和发起排障的门槛：不需要先知道该查哪些命令，也能从一个自然语言问题开始，得到一份有证据、有边界、有建议的诊断结果。这也是KubeBlocks AI Agent的核心意义：让数据库运维从“依赖少数专家手工排查”，逐步走向“人人都能发起、专家可以复核、过程可以追踪”的智能化协作。
