事情的发生经过大致是这样的：
通过客户端连测试环境做数据修改的时候，卡死执行不成功。
锁表？
第一时间想的会不会是锁表了。可以通过以下命令进行查看：
SHOW OPEN TABLES WHERE In_use >0;
该命令会显示所有正在被使用的MySQL表。如果结果中的In_use大于0，说明这个表被锁住了。
如果需要查看更具体的锁信息，例如表被哪个用户锁住了，可以使用以下命令：
SELECT
t.TABLE_SCHEMA,t.TABLE_NAME,p.ID,p.USER,p.HOST,p.DB,p.COMMAND,p.TIME,p.STATE,
l.RETRIES,l.TIMEOUT,l.SLEEP,l.TYPE
FROM
information_schema.TABLES AS t
INNER JOIN INFORMATION_SCHEMA.PROCESSLIST AS p ON p.DB = t.TABLE_SCHEMA
LEFT JOIN INFORMATION_SCHEMA.LOCKS AS l ON l.ID = p.ID
WHERE
t.TABLE_SCHEMA NOT IN ('information_schema','mysql','performance_schema')
AND p.COMMAND='Sleep'
AND l.TYPE IS NOT NULL;
该命令会列出所有被锁住的表，以及锁住表的进程信息和锁的详细信息。
也可以通过命令：
show full processlist;
查看进程。 找到锁表的进程，杀掉进程 假设进程id为46286
kill 46286;
binlog磁盘空间不足
此次我们遇到的情况并没有出现锁表的情况，并且测试环境的应用服务开始出现大量连接失败的情况。经过排查最终发现binlog的磁盘目录空间使用率达到100%，这就意味着后续的dml操作写binlog失败，导致程序卡死，资源不足。
binlog暴涨的原因是后端同步了一批300多万的数据。。。
我们决定删除部分binlog文件并重启数据库
#停止
service mysqld stop
#启动
service mysqld start
