线上突然变慢，用 ChatDBA 做一次 MySQL 会话诊断

业务接口变慢、后台任务迟迟不结束、连接数突然上升、CPU 被打满，最后往往都能在当前会话中找到线索：是谁在执行、执行了多久、跑的是什么 SQL、卡在什么状态、有没有阻塞别人、要不要先终止。

问题是，线上排障最怕一开始就猜。猜是 SQL 慢，可能其实是锁等待；猜是连接池问题，可能只是某几个会话跑了异常查询；猜是数据库整体扛不住，可能真正的问题是单条 SQL 把资源拖住了。

ChatDBA 的实时会话诊断，适合用来处理这种“先把现场看清楚”的问题。

会话诊断，先回答三个问题

一次有效的 MySQL 会话诊断，至少要回答三个问题。

第一，当前有没有异常会话。比如执行时间过长、状态异常、扫描量过大、连接来源集中、会话数量突然变多。

第二，异常会话是否正在影响其他会话。一个查询慢不一定马上造成事故，但如果它持有锁、拖住事务、占用大量资源，就可能让其他请求一起变慢。

第三，判断是否需要立刻止损。异常会话的处置要区分业务影响，有些需要先确认来源，有些可以等待完成，有些应该尽快终止并保留后续优化线索。

ChatDBA 会话诊断的价值，就在于把这三个问题放在同一个上下文里看。用户可以少做页面切换、命令复制和人工拼判断，把注意力放在影响范围和处理动作上。

从会话列表到可执行建议

在 NineData 中接入 MySQL 数据源后，用户可以让 ChatDBA 结合当前实例上下文分析实时会话。它会关注正在运行的 SQL、会话持续时间、用户、来源主机、数据库、等待状态等信息，并把可疑会话整理出来。

如果某个会话执行时间明显过长，ChatDBA 会提示它为什么可疑；如果某条 SQL 可能是高成本查询，会提示后续可以进入 SQL 智能优化；如果会话存在锁等待或阻塞关系，则可以继续追问锁诊断，让 ChatDBA 找出阻塞源。

更重要的是，ChatDBA 可以给出止损动作的建议，例如建议的 kill 会话命令、执行前需要确认的业务影响，以及后续应该如何复盘这条 SQL 或应用请求。

这对线上排障很关键。因为真正紧急的时候，团队需要的是一个清晰判断：哪个会话最危险，为什么危险，现在能不能处理，处理后还要做什么。

开发和运维看到的是同一个现场

会话问题经常横跨开发和运维。

运维看到数据库压力升高，开发需要知道是哪段业务 SQL；开发看到接口超时，运维需要判断数据库里是否已经堆了会话。双方如果各查各的，就很容易出现信息断层。

ChatDBA 的对话式诊断可以把现场描述得更一致。它既能给运维人员提供会话级排障入口，也能让开发人员理解某个 SQL 为什么会拖慢实例。对于不熟悉 SHOW PROCESSLIST、information_schema 或 InnoDB 事务视图的人来说，这种自然语言解释可以减少很多理解成本。

这也是 AI 原生数据库管理平台的意义之一：是把复杂的数据库现场翻译成团队都能理解的决策语言。

止损之后，还要沉淀

会话诊断不能只停在“这次 kill 掉了”。

如果同类会话反复出现，说明问题可能在应用逻辑、SQL 写法、索引设计、连接池配置或任务调度策略里。ChatDBA 可以在同一会话中继续追问，例如：