新增HikariDataSource后查询性能骤降，求优化方案

嘿，我之前也碰到过类似的情况——换了Hikari解决了连接断开问题，结果性能直接跳水。结合你的场景，给你列几个优先级最高的优化点，都是实际踩坑后验证有效的：

1. 先把连接池的“自动伸缩”关了！ #

Hikari默认会自动收缩空闲连接，这在业务波动大的时候会导致频繁销毁/创建连接，这可是性能杀手！直接把 minimumIdle 设置成和 maximumPoolSize 一样的数值，让连接池保持固定大小，避免连接创建的开销。比如：

hikariConfig.setMinimumIdle(10); // 和max保持一致
hikariConfig.setMaximumPoolSize(10);

另外，把 idleTimeout 调大一点（比如设成300000，也就是5分钟），或者直接设为0禁用自动回收——只要你的数据库允许长期保持连接，这步能立竿见影减少连接波动。

2. 别让连接有效性检查拖后腿 #

很多人会给Hikari加 connectionTestQuery 比如SELECT 1，但JDBC4+已经支持原生的isValid()方法，比执行SQL快多了！直接删掉这个配置，让Hikari用原生检查。如果必须保留，也用最轻量化的语句（比如MySQL用SELECT 1，Oracle用SELECT 1 FROM DUAL），同时把 validationTimeout 设为5000（5秒），别让它频繁触发。

3. 排查是不是连接泄漏了！ #

如果代码里没正确关闭连接（比如try-with-resources写漏了），连接池会被耗尽，后续请求都在等连接，自然慢得离谱。开启Hikari的泄漏检测：

hikariConfig.setLeakDetectionThreshold(2000); // 超过2秒没归还连接就打日志

然后看日志里有没有连接泄漏的警告，找到那些没正确释放连接的代码段，这是很多人忽略的点！

4. 别只盯着连接池，数据库端也要查 #

性能暴跌不一定是Hikari的锅，可能是换数据源后SQL执行计划变了：

• 用数据库的EXPLAIN命令分析你的分页查询和200条数据的SQL，看看是不是索引失效、全表扫描了——之前毫秒级，现在几十秒，大概率是执行计划出问题了。
• 检查数据库的超时设置，比如MySQL的wait_timeout和interactive_timeout，要比Hikari的idleTimeout大，避免数据库主动断开连接，导致Hikari拿到失效连接还要重试。

5. 一些细节优化，积少成多 #

• 开启Hikari的DEBUG日志，看看连接获取、释放的耗时，到底是连接池慢还是数据库查询慢，精准定位问题。
• 如果业务不需要自动提交，把autoCommit设为false，减少事务提交的开销。
• 针对MySQL，开启PreparedStatement缓存，减少SQL解析的时间：

  hikariConfig.addDataSourceProperty("cachePrepStmts", "true");
  hikariConfig.addDataSourceProperty("prepStmtCacheSize", "250");
  hikariConfig.addDataSourceProperty("prepStmtCacheSqlLimit", "2048");
  

建议你先从第一步调整连接池大小开始试，这步见效最快。如果还是慢，再排查连接泄漏和数据库端的问题，应该能解决你的性能问题。

内容的提问来源于stack exchange，提问作者Jose