mysql的cpu占用达到100%;show processlist命令查看 会出现1000多个lock...
发布网友
发布时间：2022-04-23 00:52
共2个回答
热心网友
时间：2022-04-08 01:30
如果不允许重启，我提供一个shell脚本，生成 kill id命令杀掉lock线程，如下：
------------------------------------
#!/bin/bash
mysql -u root -e "show processlist"|grep -i "Locked" >> locked.txt;
for line in awk '{print $1}' locked.txt
do
echo "kill $line;">>kill_lock.sql
done
----------------------------------
执行完脚本后，会生成kill_lock.sql文件，内容类似如下：
kill 1;
kill 2;
kill 3;
-------------------这些对应的都是lock的sessionid，直接复制文件里的内容，然后在mysql里执行就ok 了
至于排查哪条sql引起的，这个有点难了，不过你可以尝试开启慢查日志和无索引日志来确认比较耗时的查询，避免再次出现堵塞追问感谢，这些我也做过，但不治本。
追答那是否开启了慢查日志？
要想治本，那就需要好好整顿了，sql需要优化，表结构不合理的话也需要调整
热心网友
时间：2022-04-08 02:48
可以看到很多有用的信息：
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 掉就是了。
