问题

我的 MySQL CPU 高了，看了一下 processlist，切实有太多行了，我要不要筹备辞职？

试验

MySQL CPU 飚高的起因有很多种，咱们先剖析一种最简略常见的。

还是先建个数据库：

还是依照之前试验 11 的技巧，疾速造一些数据：

重复执行最初一句 SQL：

上面来执行一条比拟坑的 SQL，让 CPU high 起来：

当初咱们忘掉之前做了什么，就来解决这个 CPU 高的问题。

先用 top -H 找到 CPU 高的线程，这里能够看到 CPU 高的线程始终是 17967

（如果 CPU 高的线程号始终在变，那可能不是单个 SQL 引起的 CPU 耗费，须要用其余办法来辅助剖析，办法咱们当前会介绍）

找到这个线程的工作：

能够看到很多有用的信息：

1. 能够看到 processlist 中对应这根线程的信息

2. 能够找到其在 processlist 中的 ID，这样咱们就能够下 kill 命令来完结 SQL

小贴士：

应用 performance_schema 时，须要大家留神 MySQL 应用了多个线程编号，源自于不同视角：
1. PROCESSLIST_ID：在 processlist 中的编号，是使用者视角的编号，使用者能够间接用 kill 命令。
2. THREAD_ID：是 MySQL 外部应用的线程编号，是 MySQL 外部视角的编号。
3. THREAD_OS_ID：是在操作系统上，对应的线程编号，是操作系统视角的编号。
大家应用时须要辨别好，不要 kill 错了 SQL。

咱们再来找找其余有用的信息：

能够看到 SQL 执行的开始工夫，正在应用了一张长期磁盘表。

如果开启了 performance_schema 的其余监控项，通过 Thread_ID 关联，能够找到更多信息。

当然，眼下这么显著的坑 SQL，咱们 kill 掉就是了。

对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！