MySQL CPU 占用高怎么查？AI Agent 分析进程、SQL 和索引问题

MySQL CPU 占用高通常是业务突发增长或 SQL 写法烂导致的，在主机选的运维实战中，遇到数据库把 CPU 吃满，别急着重启，先搞清楚是哪个进程在作妖。本文带你用传统命令结合 AI Agent 分析进程，快速定位并解决 SQL 和索引问题，把数据库负载降下来。

紧急定位 MySQL CPU 占用高

遇到 CPU 飙升，第一步不是看配置，而是看当前谁在干活。很多人直接去改配置文件，其实方向完全错了。

使用 top/htop 锁定进程

登录服务器，输入 `top` 或 `htop`，按 `P`（大写）按 CPU 排序。确认是不是 `mysqld` 进程霸占了资源。如果是，记下 PID，接下来进数据库内部查。

查看 Processlist 锁定可疑 SQL

进入 MySQL 命令行，执行以下命令查看当前连接和执行状态：

mysql -u root -p

sql
show full processlist;

重点关注 `Command` 列为 `Query` 的行，特别是 `Time`（执行时间）很长、`State` 处于 `Sending data`、`Copying to tmp table` 或 `Sorting result` 状态的 SQL。这些通常是罪魁祸首。

如果某个 SQL 明显卡死，且业务允许，可以先紧急终止：

sql
kill <线程ID>; — 替换为对应的 Id

这只是治标，治本还得靠分析日志。

开启慢查询日志采集数据

为了事后复盘和让 AI Agent 分析，我们需要开启慢查询日志。这个操作影响很小，生产环境也可以开。

临时开启慢查询配置

不需要重启服务，直接在 MySQL 命令行执行：

sql
set global slow_query_log = 'ON'; — 开启慢查询
set global long_query_time = 1; — 记录执行超过 1 秒的 SQL
set global log_queries_not_using_indexes = 'ON'; — 记录没走索引的查询

导出日志样本

慢查询日志通常位于 `/var/log/mysql/` 或 `/var/lib/mysql/` 下，文件名一般是 `hostname-slow.log`。不要把整个日志扔给 AI，先截取最近的一百行：

tail -n 100 /var/log/mysql/mysql-slow.log > slow_query_sample.log

AI Agent 辅助分析 SQL 性能

人工看慢查询日志费时费力，利用 AI Agent 分析进程和日志能极大提高效率。这里的核心是“投喂数据”，而不是让 AI 瞎猜。

构建分析 Prompt

你可以将刚才导出的 `slow_query_sample.log` 内容，或者 ow processlist` 的结果，喂给 AI Agent（如通过 OpenAI API 或本地部署的 Ollama）。Prompt 可以这样写：

> “你是一名资深 DBA。以下是一段 MySQL 慢查询日志和当前的进程列表。请分析其中导致 CPU 占用高的 SQL 语句，指出是否存在全表扫描、文件排序或临时表使用，并给出具体的优化建议或索引修改方案。”

结合 EXPLAIN 结果诊断

AI 建议后，必须回归验证。把可疑 SQL 拿出来，在前面加上 `explain`：

sql
explain select * from your_table where status = 1 order by created_at desc;

关注输出中的 `type` 和 `key` 字段：
* `type = ALL`：全表扫描，这是性能杀手，必须加索引。
* `key = NULL`：没用到索引。
* `rows`：预估扫描行数，数值越大越慢。

把 `explain` 的结果也发给 AI Agent，让它判断索引是否生效，或者是否需要覆盖索引。

SQL 和索引问题的实战修复

分析出问题后，就是动手改的时候。

添加合适索引

如果 AI Agent 指出 `where` 后面的字段没走索引，或者 `order by` 导致排序效率低，通常需要添加联合索引。

sql
— 假设 SQL 是 where status=1 order by created_at
alter table your_table add index idx_status_created (status, created_at);

注意：生产环境加索引会锁表，建议在低峰期执行，或者使用 `pt-online-schema-change` 工具在线变更。

优化查询写法

有些问题不是缺索引，是 SQL 写得太烂。常见坑点：
* `SELECT *`：只查需要的字段，减少 I/O。
* `LIKE '%abc%'`：前缀模糊索引失效，尽量改成 `LIKE 'abc%'` 或用全文索引。
* 在索引列上做运算：如 `where year(created_at) = 2023`，这会导致索引失效，应改为 `where created_at between '2023-01-01' and '2023-12-31'`。

老鸟叮嘱

1.别把生产数据直接发给公网 AI：在把日志或 SQL 发给 ChatGPT 等公网服务前，务必脱敏，把表名、字段名、关键数据替换成占位符，防止数据泄露。
2.索引不是越多越好：索引会占用磁盘并降低写入速度，只加必要的索引。
3.AI 只能辅助决策：AI Agent 分析进程和 SQL 的结果仅供参考，最终执行 `DROP` 或 `ALTER` 命令前，一定要自己在测试环境验证。
4.关注硬件瓶颈：如果 SQL 已经优化得很好，CPU 依然满载，可能是内存太小导致频繁刷盘，或者是 CPU 算力本身不够，这时候就得考虑升级 VPS 配置了。

FAQ

MySQL CPU 占用高直接 Kill 进程可以吗？
可以紧急 Kill 掉长时间运行或锁表的线程，但频繁 Kill 可能会导致业务报错或数据不一致，仅作为止血手段。

慢查询日志会写满磁盘吗？
长期开启且流量大的情况下可能会。建议配置 `slow_query_log_file` 轮转策略，或者定期清理旧日志。

AI Agent 能直接连生产数据库改数据吗？
绝对不行。AI Agent 只能做分析提供建议，赋予它直接修改生产库的权限是极度危险的，容易造成毁灭性后果。

为什么加了索引 CPU 还是很高？
可能是缓存命中率低（Buffer Pool 太小），或者是并发连接数太多导致上下文切换频繁，需要检查 `max_connections` 和内存配置。