当前位置：首页 > news >正文

druid连接池参数配置

news 来源：原创 2025/7/17 19:27:22

最近发现生产环境经常有数据库连接超时的问题，排查发现是druid连接池参数设置不合理导致

总结问题如下：

为了防止僵尸连接，k8s ipvs做了连接超时限制，如果TCP连接闲置超过900s(15分钟)，客户端再尝试通过这个连接去发起请求，数据包经过防火墙会被直接丢弃掉，无法到达服务端。
从客户端的角度来看，就是发送了数据包之后，阻塞等待服务端响应，但是很明显永远都不可能得到响应，自然就超时了。
所以在配置连接池的时候，需要避免连接长期闲置不释放；或者如果需要长期保留一些连接不释放，要有对应的连接保活机制

druid连接池配置属性介绍：https://github.com/alibaba/druid/wiki/DruidDataSource%E9%85%8D%E7%BD%AE%E5%B1%9E%E6%80%A7%E5%88%97%E8%A1%A8

下面介绍一下对我们影响较大的一些参数：

参数名	建议值	参数说明
connectionProperties		不同数据库配置属性值有差异，比如pg的loginTimeout单位是秒（新版druid也是毫秒），MySQL是毫秒 pg建议配置： druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5;connectTimeout=5;socketTimeout=60 注意：新版druid(1.2.17开始)要求配置druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5000;connectTimeout=5000;socketTimeout=60000 MySQL建议配置： druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000;loginTimeout=5000;connectTimeout=5000;socketTimeout=60000connectTimeout为建立数据库连接的超时时间；如果不设置loginTimeout，会在当前线程直接去建立连接；设置了loginTimeout，则会创建异步线程去建立连接。推测是为了防止底层系统阻塞，导致上层应用线程挂死； socketTimeout即readTimeOut，最大sql执行时间
maxWait	5000	获取连接时最大等待时间，单位毫秒。默认-1 这个只是从连接池单次获取连接的等待时间，真正的建立数据库连接的超时时间，由上面的loginTimeout、connectTimeout决定注意不能把maxWait理解为应用获取连接的最大耗时，因为这里只是单次从连接池获取连接的等待时间，实际获取连接的实现是一个无限循环：获取连接 → 校验连接 → 校验不通过则继续获取新的连接直到校验通过所以我们把maxWait和validationQuery都设置为5s的时候，出现了实际获取连接耗时10s的情况，这是因为两次获取的连接都是僵尸连接，执行validationQuery的时候超时失败，第三次才获取到正常的连接
maxActive	20~50 根据应用具体情况设置，不建议设置太大	最大连接池数量
minIdle	0~5	最小连接池数量如果没有配置maxEvictableIdleTimeMillis，则minIdle应该配置为0
initialSize	0~5	初始化时建立物理连接的个数
timeBetweenEvictionRunsMillis	30000	有两个含义： 1) Destroy线程会检测连接的间隔时间，如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接。 2) testWhileIdle的判断依据，详细看testWhileIdle属性的说明
minEvictableIdleTimeMillis	60000	连接保持空闲而不被驱逐的最小时间，超过minIdle的连接，空闲时间大于这个值会被驱逐
maxEvictableIdleTimeMillis	120000	连接保持空闲而不被驱逐的最大时间，默认7小时 minIdle的连接，空闲时间大于这个值会被驱逐之前就是因为这个值没有设置，且minIdle大于0，所以连接一直不会被驱逐
validationQuery	SELECT 1	用来检测连接是否有效的sql 如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用
validationQueryTimeout	5	单位：秒，检测连接是否有效的超时时间，根据配置选择使用发送ping或者执行validationQuery sql的方式进行连接校验之前数据网关接口耗时30s多一点，其原因就是这个值配置为30s
testWhileIdle	true	申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效
testOnBorrow	false	申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能
testOnReturn	false	归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能
keepAlive	true	连接池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作这个参数可能不会生效，最好不要依赖它来做连接保活
poolPreparedStatements	false	是否缓存preparedStatement，也就是PSCache。PSCache对支持游标的数据库性能提升巨大，比如说oracle。在mysql下建议关闭。 pg也建议关闭
connectionErrorRetryAttempts	1	异步创建连接的线程，在创建连接失败后会会进行计数，当errorCount小于等于connectionErrorRetryAttempts时会立刻进行失败重试。当errorCount大于connectionErrorRetryAttempts时，默认情况会sleep timeBetweenConnectErrorMillis(默认500ms)后再进行重试
timeBetweenConnectErrorMillis	500	默认500ms 见上面connectionErrorRetryAttempts释义
breakAfterAcquireFailure	false	注意这个值千万不要设为true 设为true，一旦创建数据库连接失败，创建连接的异步线程就会终止，导致的结果就是，偶尔的网络波动，会导致应用后续一直获取连接失败，即使网络恢复正常参见：https://github.com/alibaba/druid/issues/2862

这里特别想吐槽下connectionProperties参数的设置，pg的设置原本单位是秒，1.2.17特意改成毫秒(可以看下面的代码对比)。虽然从统一性角度来说，确实用毫秒比较合理。但是对使用者来说，从低版本升级到高版本，参数配置突然就有问题了。真的很不友好

相关文章：