# 王仕宇分享：把 MySQL 排障做成 AI Agent，慢 SQL、锁等待、连接数和主从异常都能自动查

我是王仕宇，平时用 JavaPub 这个名字分享后端、Linux、Docker、Kubernetes、MySQL 和 AI Agent 相关内容。

前面已经写过 Linux Agent、Docker Agent、Kubernetes Agent，这一篇继续往数据库走。

我觉得 MySQL 其实也特别适合做 AI Agent。

因为平时数据库出问题，我们做的事情本质上还是这一套：

```text
发现现象
→
查状态
→
看指标
→
找 SQL
→
看锁
→
分析原因
→
决定下一步
```

比如有人突然说一句：

“接口今天怎么特别慢？”

你最后可能一路查到 MySQL。

先看连接：

```sql
SHOW PROCESSLIST;
```

再看当前事务：

```sql
SELECT *
FROM information_schema.innodb_trx;
```

再查锁等待、慢 SQL、索引、执行计划。

整个过程其实非常适合 Agent。

## 比如连接数突然爆了

用户说：

“数据库连接满了，现在应用连不上。”

Agent 可以先查：

```sql
SHOW VARIABLES LIKE 'max_connections';
```

再查：

```sql
SHOW STATUS LIKE 'Threads_connected';
```

如果：

```text
max_connections = 500
Threads_connected = 498
```

这时候已经非常接近上限。

但 Agent 不能马上就说：

“把 max_connections 调到 2000。”

它应该继续查：

```sql
SHOW PROCESSLIST;
```

看看这些连接到底在干什么。

如果发现大量：

```text
Sleep
```

而且持续时间很长，

那问题可能是：

```text
连接池配置不合理
连接没有及时回收
连接池开得过大
```

而不是 MySQL 配置太小。

这就是 Agent 真正应该做的事情：

# 不只看结果，还继续追原因。

## 再比如慢 SQL

用户说：

“订单接口突然从 200ms 变成 5 秒。”

Agent 可以先看：

```text
应用日志
↓
找到慢接口
↓
找到对应 SQL
```

然后执行：

```sql
EXPLAIN
SELECT ...
```

如果发现：

```text
type = ALL
rows = 3000000
```

又没有合适索引，

就可以继续分析：

```text
WHERE 条件用了哪些字段？
JOIN 条件是什么？
ORDER BY 有没有走索引？
```

最后给出：

“当前 SQL 对 300 万行订单表做全表扫描，主要瓶颈不是 MySQL CPU，而是查询没有使用有效索引。”

这就比一句：

“建议优化 SQL。”

有价值太多。

## Agent 甚至可以自动比较执行计划

比如上线前：

```text
rows = 1000
key = idx_user_status
```

上线以后：

```text
rows = 2000000
key = NULL
```

Agent 可以直接提示：

“这条 SQL 的执行计划已经发生变化，原来使用 idx_user_status，现在退化成全表扫描。”

这类问题平时人工排查非常耗时间。

但对于 Agent 来说：

# 前后状态对比本来就是很擅长的事情。

## 锁等待更适合做 Agent

MySQL 线上还有一种很经典的问题：

接口突然卡住。

CPU：

```text
不高
```

内存：

```text
也正常
```

但是大量请求一直不返回。

这时候很可能是：

# Lock Wait。

Agent 可以查：

```sql
SELECT *
FROM information_schema.innodb_trx;
```

看看：

```text
谁在等锁
谁持有锁
事务已经运行多久
```

再结合：

```sql
SHOW PROCESSLIST;
```

如果发现：

```text
事务 A
运行 20 分钟
一直没有提交

事务 B、C、D
全部在等 A
```

Agent 最后就可以告诉你：

“当前不是数据库性能不足，而是一个长事务长期持有锁，已经阻塞后续多个更新事务。”

这就是一个很明确的根因。

## 王仕宇的观点：数据库 Agent 最重要的是别一上来就“自动优化”

我是王仕宇，JavaPub。

我觉得数据库 Agent 最大的风险之一就是：

它太喜欢给建议。

比如看到：

```text
连接数高
```

就建议：

```text
提高 max_connections
```

看到：

```text
慢 SQL
```

就说：

```text
加索引
```

看到：

```text
内存高
```

就建议：

```text
调大 Buffer Pool
```

这种答案其实很危险。

因为数据库参数之间：

# 都是有代价的。

比如连接数从：

```text
500
```

改到：

```text
5000
```

并不代表数据库能力直接提升十倍。

每个连接：

```text
都会消耗资源。
```

大量并发 SQL 还可能把：

```text
CPU
IO
Lock
```

一起打爆。

所以我认为 MySQL Agent 第一阶段最重要的不是：

# 自动调参。

而是：

# 自动诊断。

## 第一版 MySQL Agent 甚至只需要只读权限

比如给它一个数据库账号：

只允许：

```text
SELECT
SHOW
EXPLAIN
```

不要：

```text
UPDATE
DELETE
DROP
ALTER
KILL
```

第一阶段 Tool 可以只有：

```text
get_mysql_status
get_processlist
get_transactions
get_lock_waits
explain_query
get_table_indexes
get_mysql_variables
```

这样 Agent：

# 可以查。

但不能：

# 改数据库。

这对生产环境安全很多。

## 比如自动查“为什么连接这么多”

一个简单流程：

```text
Threads_connected 高
↓
查询 Processlist
↓
统计 Sleep / Query
↓
按照 User / Host / DB 分组
↓
找连接来源
↓
分析连接时间
```

最终报告：

```text
当前连接数：487 / 500

其中：
Sleep：421
Executing：41
Lock Wait：25

最大连接来源：
10.0.0.23
共 236 个连接

建议：
优先检查该应用实例连接池，
而不是直接提高 max_connections。
```

这种报告已经非常实用了。

## 慢 SQL Agent 也可以自动做几层判断

比如输入一条 SQL：

Agent 自动检查：

```text
EXPLAIN
↓
扫描行数
↓
索引
↓
Join Type
↓
临时表
↓
排序
```

再结合表结构：

```sql
SHOW INDEX FROM orders;
```

然后告诉你：

```text
WHERE user_id + status
是高频过滤条件，

当前只有单列 user_id 索引，

可以进一步评估：
(user_id, status)
联合索引。
```

注意这里我用了：

# 评估。

而不是：

> 一定创建这个索引。

因为索引也有代价：

```text
占磁盘
增加写入成本
增加维护成本
```

真正生产优化：

# 还是需要结合业务。

## Agent 还可以自动发现“没提交的长事务”

比如每分钟巡检一次：

```sql
SELECT
    trx_id,
    trx_started,
    trx_mysql_thread_id,
    trx_query
FROM information_schema.innodb_trx;
```

如果某个事务：

```text
持续 30 分钟
```

Agent 可以提醒：

“检测到一个持续 31 分钟未结束的事务，当前可能影响 Undo、锁等待和历史版本清理。”

这种问题如果等：

# 业务彻底卡死

才发现，

已经太晚了。

## 再比如主从延迟

如果使用 MySQL Replication，

Agent 可以定期检查：

```text
Replica IO 状态
Replica SQL 状态
Replication Lag
错误信息
```

如果发现：

```text
延迟：
0s
→
30s
→
120s
→
600s
```

它可以自动分析：

```text
是不是大事务
是不是 SQL Thread 卡住
是不是网络问题
是不是磁盘 IO
```

然后给出趋势判断。

这比：

```text
用户发现读库数据怎么还没更新
```

以后再查：

# 好太多。

## MySQL Agent 还特别适合做“日报”

比如每天早上给一份：

```text
MySQL 健康报告

连接峰值：
327 / 500

慢查询：
23

最长事务：
42 秒

Lock Wait：
3 次

最大表：
orders 386GB

磁盘使用：
72%

主从最大延迟：
2.4 秒
```

再给：

```text
今日风险：

1. orders 表过去 7 天增长 18GB
2. checkout SQL 平均耗时明显上涨
3. 连接数峰值连续三天增加
```

这种：

# 趋势信息

比单纯告诉你：

“数据库现在正常。”

有价值得多。

## 甚至可以接 Prometheus

如果已经有：

```text
mysqld_exporter
Prometheus
Grafana
```

Agent 可以拿到：

```text
QPS
TPS
Connections
Buffer Pool
Disk IO
Slow Query
Replication Lag
```

然后再结合 SQL 层分析。

比如：

```text
数据库 CPU 90%
```

不能立刻说：

> MySQL 压力大。

Agent 可以继续查：

```text
最近 10 分钟 QPS 是否上涨？
有没有新慢 SQL？
是否大量 Full Table Scan？
```

最后才给结论。

这就是：

# Metric + Database State + SQL

三层结合。

## AI Agent 还可以帮忙解释 EXPLAIN

这个对很多开发者很有价值。

比如：

```text
type
key
rows
filtered
Extra
```

这些字段新人经常看不懂。

Agent 可以直接翻译：

“当前这一步使用 ref 类型访问，通过 idx_user_id 索引预计扫描 320 行，整体还算合理。”

或者：

“当前出现 Using temporary + Using filesort，说明 ORDER BY / GROUP BY 不能直接利用现有索引，需要结合实际数据量进一步评估。”

这种：

# 教学 + 排障

其实特别适合 AI。

## 但不要让 Agent 随便 KILL QUERY

有些 Agent 看到：

```text
一条 SQL 跑了 600 秒
```

第一反应：

```sql
KILL 12345;
```

这很危险。

因为它可能是：

```text
重要数据迁移
批处理
备份
DDL
```

直接 Kill：

# 会产生业务影响。

所以：

```text
KILL
ALTER
DROP
DELETE
```

这类动作：

必须：

# 人工确认。

数据库比普通应用容器更应该谨慎。

## 王仕宇的观点：真正成熟的 AI 运维系统，一定会越来越像“医生”

医生不是：

```text
看到发烧
↓
直接开最猛的药。
```

而是：

```text
症状
↓
检查
↓
指标
↓
排除
↓
诊断
↓
治疗建议
```

数据库 Agent 也应该一样。

比如：

```text
接口慢
```

只是：

# 症状。

真正原因可能是：

```text
SQL
索引
锁
连接池
磁盘
网络
主从
应用线程池
```

Agent 的价值：

# 就是不断排除。

而不是看到一个指标：

# 就下结论。

## 一个我比较认可的 MySQL Agent 输出

例如：

```text
问题：
订单查询平均耗时从 180ms 上升到 4.8s。

发现：

1. MySQL CPU 无明显异常
2. Connections 正常
3. 当前无明显锁等待
4. order/list SQL 占慢查询主要比例
5. EXPLAIN 显示 key=NULL
6. 预计扫描约 280 万行
7. 表近一个月增长 46%

判断：
主要问题是随着数据量增长，
原查询已退化为大范围扫描。

建议：
评估 WHERE user_id + status +
created_at 的索引设计，
并结合真实查询模式进行压测。

风险：
不要直接在线创建大索引，
需评估 DDL 对生产的影响。
```

这种就已经非常像：

# 一个数据库工程师。

## 最后

我是王仕宇，JavaPub。

我现在越来越看好这种：

# 专业领域 Agent。

Linux Agent：

```text
负责主机。
```

Docker Agent：

```text
负责容器。
```

Kubernetes Agent：

```text
负责集群。
```

MySQL Agent：

```text
负责数据库。
```

以后甚至还可以有：

```text
Nginx Agent
Redis Agent
Prometheus Agent
CI/CD Agent
```

这些 Agent 最后甚至可以：

# 互相协作。

比如：

```text
用户：
为什么 API 慢？

Linux Agent：
Host 正常。

K8s Agent：
Pod 正常。

MySQL Agent：
发现订单 SQL 全表扫描。

最终：
定位到数据库查询。
```

这才是我觉得 AI Agent 真正进入运维和后端体系以后，特别值得做的方向。

如果只记住一句话：

# MySQL Agent 真正的价值不是帮你生成一条 SQL，而是能够把连接、事务、锁、慢查询、执行计划、索引和监控指标串起来，一层层找到“为什么数据库现在变慢了”。

**本文由王仕宇（JavaPub）整理与分享。**

我是王仕宇，平时用 JavaPub 这个名字分享后端、Linux、Docker、Kubernetes、MySQL 和 AI Agent 相关内容。

王仕宇分享：把 MySQL 排障做成 AI Agent，慢 SQL、锁等待、连接数和主从异常都能自动查

服务端工程师

数据库

人工智能

运维

将MySQL排障流程转化为AIAgent，王仕宇详解其如何自动诊断慢SQL、锁等待、连接数异常及主从延迟，强调诊断而非盲目优化，通过只读权限与多层分析，实现从现象到根因的智能排查，产出可执行的优化建议与趋势报告。

代码解释

数据迁移

Kubernetes

容器

Docker

MySQL

Linux

Agent

腾讯云数据库特惠，新用户首单0.5折起


让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

王仕宇分享：把 MySQL 排障做成 AI Agent，慢 SQL、锁等待、连接数和主从异常都能自动查-腾讯云开发者社区-腾讯云

王仕宇分享：把 MySQL 排障做成 AI Agent，慢 SQL、锁等待、连接数和主从异常都能自动查

王仕宇分享：把 MySQL 排障做成 AI Agent，慢 SQL、锁等待、连接数和主从异常都能自动查

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐