判断之后，立马利用navicat连接数据库，查询进程数：进入information_schema库，查询PROCESSLIST 表，可以看到用户，IP，数据库名称等，根据COMMAND和INFO 可以推断出哪个功能占用数据库线程（以下图片只是用来做例子，不是当时图片）
当时查询创造的问题是：某一个模块的更新语句，在几分钟之内一贯update，把数据库连接池占用完了,导致其他模块项目连接都超时了，查询INNODB_LOCKS 表，创造大量的表被锁去世，查询INNODB_TRX 也有大量的事务一贯处理等待中
当时采纳了紧急处理：把update功能关闭掉，手动开释所有事务，利用KILL + 事务ID 杀去世事务
详细缘故原由剖析：这个数据库最大线程数只有32，虽然数据库连接数可以有一万多，但是如果连接数被占用完的话，其他连接是不能利用的，当时那个update功能，没有采取批量入库，是单条更新，这个时候昔时夜批量要求过来的时候，会把数据库连接数都占完的，为什么占完呢，这个是由于我们这个模块支配了多个节点，每个节点都配置连接数最小为10，最大50，当连接数不足用的时候，会自动扩展连接数到50，这个时候就超过数据库最大值32了
办理办法：优化功能，要用批量更新，如果是回调接口，有单条要求，可以利用MQ异步处理；开启慢查询日志（虽然会影响一点性能，但不大，可以接管），把慢查询语句优化；能不该用事务的只管即便不要用，可以短事务的绝对不用长事务（也可以业务逻辑拆分，拆成多段事务来处理）；调度每个模块的最小和最大连接数，每个模块所有节点最大连接数最好不要超过mysql线程数的三分之二，一定要留一些给其他模块利用；利用Grafana来监控数据库连接数非常情形等
如果有什么不敷，请指教，希望能帮到你
