数据库连接数超了如何解决

[KingCoding]

背景：本人一年左右 java 开发工作经验，在一家小公司干开发，数据库使用的是 MySQL,配置基本上都是默认，应用端数据库连接池使用的是 HikariCP ，也配置了一些参数，最近测试环境遇到连接数超的情况。在网上查询了一些方法看着有点迷。

尝试解决：

1 、调整数据库的 max_connections

2 、缩短系统设置的连接数的清除时间

3 、根本原因：存在长连接、慢 SQL 等占用连接不释放的情况

疑问：没有这方面的经验，请教各位前辈第二条数据库默认是 8 小时，是否建议调整呢？或者这个问题会不会还存在其他的原因呢？以及如何排查呢？

[lichis]

wait_timeout = 600
interactive_timeout = 600

时间 600 是举例

两个参数减少，防止的就是客户端不释放，导致服务的连接数满，要注意时间长度最好要覆盖到真实业务的覆盖执行时间。至于用了不释放的就不管，让连接池管理
其次你代码连接池也要增加失效链接检查配置

[Atma]

测试环境能有多少请求量？先看下是不是慢 sql

[night98]

你连接池参数总要放上来吧，还有你数据库配了多少连接数你也不放。正常就那么几种原因，问问 ai 得了

[laminux29]

如果架构没问题，无论什么生产环境，都不会出现数据库连接数量超的问题，而且你这还只是测试环境。

改一下架构，中间件没必要一直连接数据库，长时任务可以使用异步提交、查询的方式来设计。

[KingCoding]

@Atma 好的，因为系统依赖于定时同步下来的数据

[KingCoding]

@lichis 好的，谢谢

[iseki]

检查你的 SQL 执行情况，看看是不是有会话泄漏，或者某些非预期的慢查询，比如说非预期的全表扫描，虽然用户已经挂断了，但是 SQL 还在跑，用户刷新几次你炸了。排除掉明显不合理的，评估剩下的怎么解决，是提升数据库配额，还是优化系统自身。

[Cruzz]

一般都是长事务一直占着不释放，看下 mysql 的长事务，项目小就找找 sql 。屎山就写个脚本，定时给长事务杀掉，我们一般 30 分钟长事务就告警。

[cqx2005]

这种大部分是代码问题，小项目能有几个并发访问。

先解决代码问题，也就是第三个问题，通过接口响应时间排查那些接口的问题，优化代码，优化 sql 。