mysql的cpu占用达到100%；show processlist命令查看 会出现1000多个lock的语句

杀掉lock进程最快的方法是重启mysql，像你这种情况，1000多sql锁住了，最好是重启

如果不允许重启，我提供一个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引起的，这个有点难了，不过你可以尝试开启慢查日志和无索引日志来确认比较耗时的查询，避免再次出现堵塞

最近遇到了一个坑，MySQL数据库服务器硬盘容量告警，而且因为非技术原因，还不能追加硬盘。 通过监控发现，磁盘IO一直100%。直接影响就是系统处理时间越来越长，接口响应耗时也越来越多。 经过分析，发现mysql业务数据库里有好几张大表，而且这几张大表行数都在5000万以上，文件大小都在100G和150G之间。 因为这些表都是备份表，第一反应就是找DBA直接清理掉这些表。 潜意识里以为drop table 和 truncate table效率很高，都会快速完成，但事实上不是。 但意外的是，在执行drop table时，直接导致数据库挂起了，而且还发生了主从切换。 第一次尝试失败。 第一次失败反应出来的问题是，如果数据文件过大，drop table *** 作也得慎用。 那我们可以在drop table之前，想办法把数据文件逻辑清空。比如Linux硬连接的方式，具体步骤如下（假如目标表名是test）： ln test.ibd test.ibd.hdlk drop table test 此时，磁盘上真实的数据其实没删除，但数据库里的表，已经删除了。 rm test.ibd.hdlk 到此，数据就能快速清理成功了。

max_connections=1024

这个需要降低一下。

另外既然开了慢查询日志，检查一下记录，看看是些什么查询占用了大部分资源，然后优化这些查询。

如果内存够大，

query_cache_size=64M

这个参数加大至少一倍

---