年前生产环境大批项目突然重启，查看项目日志发现大量数据库连接超时，经过深思一会，判断肯定是哪个功能把数据库线程数占完，才会出现这种问题，我公司的mysql是阿里云 RDS，16核32线程。

判断之后，立马使用navicat连接数据库，查询进程数：进入information_schema库，查询PROCESSLIST 表，可以看到用户，IP，数据库名称等，根据COMMAND和INFO 可以推断出哪个功能占用数据库线程（以下图片只是用来做例子，不是当时图片）

当时查询发现的问题是：某一个模块的更新语句，在几分钟之内一直update，把数据库连接池占用完了,导致其他模块项目连接都超时了，查询INNODB_LOCKS 表，发现大量的表被锁死，查询INNODB_TRX 也有大量的事务一直处理等待中

当时采取了紧急处理：把update功能关闭掉，手动释放所有事务，使用KILL + 事务ID 杀死事务

具体原因分析：这个数据库最大线程数只有32，虽然数据库连接数可以有一万多，但是如果连接数被占用完的话，其他连接是不能使用的，当时那个update功能，没有采用批量入库，是单条更新，这个时候当大批量请求过来的时候，会把数据库连接数都占完的，为什么占完呢，这个是因为我们这个模块部署了多个节点，每个节点都配置连接数最小为10，最大50，当连接数不够用的时候，会自动扩展连接数到50，这个时候就超过数据库最大值32了

解决方式：优化功能，要用批量更新，如果是回调接口，有单条请求，可以使用MQ异步处理；开启慢查询日志（虽然会影响一点性能，但不大，可以接受），把慢查询语句优化；能不使用事务的尽量不要用，可以短事务的绝对不用长事务（也可以业务逻辑拆分，拆成多段事务来处理）；调整每个模块的最小和最大连接数，每个模块所有节点最大连接数最好不要超过mysql线程数的三分之二，一定要留一些给其他模块使用；使用Grafana来监控数据库连接数异常情况等

如果有什么不足，请指教，希望能帮到你