王仕宇分享：把 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 复制代码

改到：

text 复制代码

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

每个连接：

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）整理与分享。