MySQL 慢查询怎么分析？AI Agent 读取 slow log 并给出优化方向

MySQL 慢查询经常让 VPS 负载飙升，CPU 跑满，导致业务卡顿。传统工具能告诉你哪条 SQL 慢，但很少直接告诉你怎么改。在主机选的运维实践中，引入 AI Agent 读取 slow log，不仅能快速定位瓶颈，还能给出具体的索引优化建议，大幅提升数据库维护效率。

MySQL 慢查询日志配置与采样

要分析慢查询，得先开启日志并抓取数据。别一上来就装各种分析工具，MySQL 自带的日志功能最可靠。

登录数据库，检查当前状态：

mysql -u root -p

sql
SHOW VARIABLES LIKE 'slow_query%';
SHOW VARIABLES LIKE 'long_query_time';

默认情况下慢查询可能没开，或者阈值是 10 秒，这对高并发业务来说太宽松了。建议临时调整为 1 秒或 2 秒来抓取问题样本。

修改配置文件 `/etc/mysql/my.cnf`（或 `/etc/my.cnf`），在 `[mysqld]` 下添加：

ini
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 2

保存后重启服务：

systemctl restart mysql

注意：确保 `/var/log/mysql/` 目录存在且 MySQL 用户有写入权限，否则服务起不来。

等待一段时间，或者重现一下卡顿场景，日志里就会有内容了。不要把几个 G 的日志直接丢给 AI，它吃不消也费钱。先截取有代表性的片段，比如最近 50 条：

tail -n 50 /var/log/mysql/mysql-slow.log > slow_sample.log

使用 AI Agent 分析日志样本

这里我们用本地部署的 Ollama 跑 CodeLlama 或 Qwen2.5-Coder 模型，或者直接使用 Claude Code / DeepSeek API。核心在于 Prompt（提示词）的编写，要让 AI 理解 MySQL 的慢日志格式。

安全第一：在把日志发给 AI 之前，务必进行脱敏。用 `sed` 或手动把真实的表名、字段名里的敏感信息（如手机号、邮箱）替换掉，防止数据泄露。

sed -i 's/真实用户名/user_xxx/g' slow_sample.log

启动本地模型（以 Ollama 为例）：

ollama run codellama:instruct

将 `slow_sample.log` 的内容复制，配合以下 Prompt 发送给 AI Agent：

> 你是资深 DBA。请分析下面的 MySQL 慢查询日志。
> 1. 找出执行时间最长的 SQL 语句。
> 2. 分析可能的瓶颈（是缺少索引、索引失效、还是锁等待）。
> 3. 针对每条问题 SQL，给出具体的 `ALTER TABLE` 优化语句或改写建议。
>
> 日志内容如下：
> [粘贴日志内容]

AI Agent 通常会快速返回分析结果，指出哪张表的哪个字段没加索引，或者 `WHERE` 子句导致了全表扫描。例如，它可能会告诉你：“`SELECT * FROM orders WHERE status = 1` 在 status 列上缺少索引，建议添加 `CREATE INDEX idx_status ON orders(status);`”。

验证 AI 生成的 SQL 优化方案

AI 给的建议不能直接无脑在生产环境执行，必须验证。

拿到 AI 建议的 SQL 后，先在测试库执行，或者在生产库用 `EXPLAIN` 模拟执行：

sql
EXPLAIN SELECT * FROM orders WHERE status = 1;

关注 `type`、`key` 和 `rows` 这几列：
* `type` 为 `ALL` 说明是全表扫描，必须优化。
* `key` 列如果显示 `NULL`，说明没用上索引。
* `rows` 是预估扫描行数，越少越好。

如果 AI 建议加索引，先看表里是不是已经有类似索引。有时候 AI 会建议你加一个本来就存在的索引，或者建议你加一个过长的联合索引，导致写入性能下降。

确认无误后，再执行建索引语句：

sql
ALTER TABLE orders ADD INDEX idx_status (status);

执行完后，观察慢查询日志，看该语句的查询时间是否下降。

老鸟叮嘱

1.别把整库日志喂给 AI：Token 是有限的，也是钱。截取最慢的 Top 10 分析性价比最高。
2.警惕 AI 幻觉：AI 可能会虚构不存在的字段或表名，或者建议你删除主键。涉及 `DROP`、`DELETE`、`TRUNCATE` 的建议，一定要人工复核。
3.索引不是越多越好：频繁写入的表，索引过多会严重拖慢插入和更新速度。AI 只懂查询快慢，不懂你的业务写入压力，要权衡读写比。
4.本地部署更安全：涉及数据库日志这种核心数据，建议在 VPS 本地用 Docker 部署 Ollama 或 LocalAI，避免将内部结构暴露给公网 API。

FAQ

MySQL 慢查询日志文件太大怎么办？
可以使用 `pt-query-digest` 工具进行归档和分析，或者配置 MySQL 的 `slow_query_log_file` 轮转策略，定期清理或压缩旧日志。

AI Agent 能自动帮我修改数据库吗？
不建议开启自动执行。目前 AI Agent 仅作为“分析顾问”使用，生成 SQL 后由人工审核并执行更安全。生产环境误操作代价太大。

本地跑 AI 分析日志需要什么配置？
建议至少 4GB 内存的 VPS。如果使用 7B 参数量的模型（如 Qwen-7B-Instruct），8GB 内存会更流畅。显存不足时会占用内存和交换分区，速度较慢。

除了加索引，AI 还能给出什么建议？
优秀的 AI Agent 还能指出 SQL 写法问题，比如 `SELECT *` 浪费 IO、在索引列上做函数运算导致索引失效、子查询效率低等，并给出改写后的 SQL 语句。