13518219792
直接用MYSQL库，肯定是阻塞方式的，就是说，你的SQL语句，网络传到服务器，服务器执行完，再把结果通过网络发回来，你调用的接口才会返回；所以，崩溃的话，肯定是自己代码有BUG的了，不会是异步导致的；
秀峰网站制作公司哪家好，找创新互联公司！从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设公司等网站项目制作，到程序开发，运营维护。创新互联公司成立于2013年到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选创新互联公司。
mysql有最大连接数设置，如果，没有关闭连接，会导致阻塞。
可以使用下面命令查看最大连接数：
show variables like '%max_connections%';
查看当前mysql连接数：
show processlist;
产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之
一不满足，就不会发生死锁。
现象是，系统里的java连接mysql超时了，
于是去mysql的机器，查看/var/log/messages日志，查对应的时间点的情况
发现mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系统的负载也到达了50的样子
用mpstat查看cpu情况
好明显，都在等io
用iostat查看io情况，%util的值，一直在80%，99%之间变化
以为磁盘有问题，用dd测下速看看
从上面的结果看，也还好，没问题
以为可能磁盘有坏道，用下面命令也扫了一遍，没问题
结果也没有坏的块，这个过程，很耗时。
用show processlist命令查看mysql正在忙着什么，一看，也没什么任务在执行的
想看看mysql，研究写哪个文件时，最耗时的
从上面结果来看，xxl_job是最耗时的。知道点眉目了，因为公司的定时任务是用的xxljob，定时任务里，有每几秒执行的任务，我猜它的日志记录一定很大，于是查看一下
我的天，这个表的记录有千万！！！这些记录，没做定时任务来清理，由于都是一些没用的记录，所以这个表的数据我全清了
清了之后，再用iostat查看
%util一下子就降下来了，用iotop查看mysql进程的io也下降了
cpu的iowait也下降了
定义一个事件，让mysql定时清理30天前的日志记录
记录一下，希望对有需要的朋友也起一点提示
