连接池连接数设置为多少合适
HikariCP为这么快？
字节码级别优化（很多⽅方法通过 JavaAssist ⽣生成）
大量细节优化
用 FastStatementList 代替 ArrayList
无锁集合 ConcurrentBag
代理类的优化（⽐如，用 invokestatic 代替了 invokevirtual，减少字节码指令行数）
配置
## 数据源配置
spring.datasource.hikari.maximumPoolSize=5
spring.datasource.hikari.minimumIdle=5
# 连接最大空闲时间，超出后连接销毁
spring.datasource.hikari.idleTimeout=600000
# 连接超时时间
spring.datasource.hikari.connectionTimeout=30000
# 池中连接的最长使用时间，超出这个时间连接归还后就会销毁
spring.datasource.hikari.maxLifetime=1800000
springboot2.x默认连接池从Tomcat换成了Hikari。
使用DataSourceAutoConfiguration加载数据源配置，其中使用@Import注入数据源配置DataSourceConfiguration。
@Configuration(proxyBeanMethods = false)
@Conditional(PooledDataSourceCondition.class)
@ConditionalOnMissingBean({ DataSource.class, XADataSource.class })
@Import({ DataSourceConfiguration.Hikari.class, DataSourceConfiguration.Tomcat.class,
DataSourceConfiguration.Dbcp2.class, DataSourceConfiguration.OracleUcp.class,
DataSourceConfiguration.Generic.class, DataSourceJmxConfiguration.class })
protected static class PooledDataSourceConfiguration {
}
abstract class DataSourceConfiguration {
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(HikariDataSource.class)
@ConditionalOnMissingBean(DataSource.class)
@ConditionalOnProperty(name = "spring.datasource.type", havingValue = "com.zaxxer.hikari.HikariDataSource",
matchIfMissing = true)
static class Hikari {
@Bean
@ConfigurationProperties(prefix = "spring.datasource.hikari")
HikariDataSource dataSource(DataSourceProperties properties) {
HikariDataSource dataSource = createDataSource(properties, HikariDataSource.class);
if (StringUtils.hasText(properties.getName())) {
dataSource.setPoolName(properties.getName());
}
return dataSource;
}
}}
Alibaba Druid
Druid连接池是阿里巴巴开源的数据库连接池项目。 Druid连接池为监控而生，内置强大的监控功能，监控特性不影响性能。功能强大，能防SQL注入，内置Logging能诊断Hack应用行为。
实用功能：
强大的监控
ExceptionSorter，针对主流数据库的返回码都有支持
SQL防注入
数据源加密配置
提供很多扩展点，方便扩展。
springboot2.x使用druid尽量剔除掉默认hikaricp连接池。
其他连接池问题
数据库连接池的选择
首先考虑可靠性和性能
功能。类似监控
可运维性。例如密码加密
可扩展性。例如添加TraceId，打印sql，通过数据库连接池更加通用。
其他：社区活跃度。
数据库连接池的最大连接数在实际项目中怎么定
数据库连接池连接数设置
Oracle Real-World Performance 小组做过这样的实验：在没有任何其他更改的情况下，仅减少连接池大小就将应用程序的响应时间从约 100 毫秒减少到约 2 毫秒——提高了 50 倍以上。
计算的基本定律是，给定单个 CPU 资源，顺序执行A和B总是比通过时间切片“同时”执行A和B快。一旦线程数超过 CPU 内核数，添加更多线程就会变慢，而不是变快。
数据库的主要瓶颈可以概括为三个基本类别：CPU、磁盘、网络。内存，与磁盘和网络相比，带宽有几个数量级的差异。例如，磁盘存在寻道成本和旋转成本，在此期间（“I/O 等待”），连接/查询/线程只是“阻塞”等待磁盘。网络同样容易出现阻塞。
经验公式
连接数 = ((core_count * 2) + Effective_spindle_count)
一个硬盘的小型 4 核 i7 服务器应该运行以下连接池： 9 = ((4 * 2) + 1).
业务场景
对于并发访问，可以采用小的数据库连接池，然后将剩下的业务线程放在队列中等待。
如果系统中混合了长事务和短事务，正确的做法应该是创建两个连接池，一个服务于长事务，一个服务于"实时"查询，也就是短事务。
连接池配置原文