在工作中常常要和各种连接池组件打交道，各种参数眼花撩乱，再也不想因为连接池配置光顾度娘了。明天总结的次要是几大罕用的数据库连接池配置，redis 连接池筹备 ing。内容次要来自各官网文档。
Druid
官网文档：https://github.com/alibaba/dr…
| 配置 | 缺省值 | 阐明 | 性能优化 | 备注 |
|---|---|---|---|---|
| name | null | 配置这个属性的意义在于，如果存在多个数据源，监控的时候能够通过名字来辨别开来。如果没有配置，将会生成一个名字，格局是：”DataSource-” + System.identityHashCode(this). 另外配置此属性至多在 1.0.5 版本中是不起作用的，强行设置 name 会出错。详情 - 点此处。 | / | / |
| url | null | 连贯数据库的 url，不同数据库不一样。例如：mysql : jdbc:mysql://10.20.153.104:3306/druid2 oracle : jdbc:oracle:thin:@10.20.149.85:1521:ocnauto | / | / |
| username | null | 连贯数据库的用户名 | / | / |
| password | null | 连贯数据库的明码。如果你不心愿明码间接写在配置文件中，能够应用 ConfigFilter。具体看这里 | / | / |
| driverClassName | 依据 url 自动识别 | 这一项可配可不配，如果不配置 druid 会依据 url 自动识别 dbType，而后抉择相应的 driverClassName | / | / |
| initialSize | 初始化时建设物理连贯的个数。初始化产生在显示调用 init 办法，或者第一次 getConnection 时 | 能够配置和 maxActive 雷同数量 | / | |
| maxActive | 8 | 最大连接池数量 | / | / |
| maxIdle | 8 | 曾经不再应用，配置了也没成果 | / | / |
| minIdle | null | 最小连接池数量 | 倡议配置和 maxActive 雷同数量 | / |
| maxWait | null | 获取连贯时最大等待时间，单位毫秒。配置了 maxWait 之后，缺省启用偏心锁，并发效率会有所降落，如果须要能够通过配置 useUnfairLock 属性为 true 应用非偏心锁。 | / | / |
| dataSouce.setUseUnfairLock(true) | 配置了 maxWait 之后，缺省启用偏心锁，并发效率会有所降落 | / | / | |
| poolPreparedStatements | false | 是否缓存 preparedStatement，也就是 PSCache。PSCache 对反对游标的数据库性能晋升微小，比如说 oracle。在 mysql 下倡议敞开。 | oracle 下能够配置 | / |
| maxPoolPreparedStatementPerConnectionSize | -1 | 要启用 PSCache，必须配置大于 0，当大于 0 时，poolPreparedStatements 主动触发批改为 true。在 Druid 中，不会存在 Oracle 下 PSCache 占用内存过多的问题，能够把这个数值配置大一些，比如说 100 | oracle 下能够配置 | / |
| validationQuery | null | 用来检测连贯是否无效的 sql，要求是一个查问语句，罕用 select ‘x’。如果 validationQuery 为 null，testOnBorrow、testOnReturn、testWhileIdle 都不会起作用。 | / | / |
| validationQueryTimeout | null | 单位：秒，检测连贯是否无效的超时工夫。底层调用 jdbc Statement 对象的 void setQueryTimeout(int seconds)办法 | / | / |
| testOnBorrow | true | 申请连贯时执行 validationQuery 检测连贯是否无效，做了这个配置会升高性能。 | 不倡议配置 | / |
| testOnReturn | false | 偿还连贯时执行 validationQuery 检测连贯是否无效，做了这个配置会升高性能。 | 不倡议配置 | / |
| testWhileIdle | false | 倡议配置为 true，不影响性能，并且保障安全性。申请连贯的时候检测，如果闲暇工夫大于 timeBetweenEvictionRunsMillis，执行 validationQuery 检测连贯是否无效。 | 倡议取代 testOnBorrow 和 testOnReturn，其会影响获取 db 连贯时的性能 | 配合 testWhileIdle=true 和 timeBetweenEvictionRunsMillis 来优化，无需在每次借用和偿还连贯时检测连贯可用性，而是定期在连贯闲暇时进行检测，缩小性能损耗 |
| keepAlive | false（1.0.28） | 连接池中的 minIdle 数量以内的连贯，闲暇工夫超过 minEvictableIdleTimeMillis，则会执行 keepAlive 操作。 | / | / |
| defualtAutoCommit | true | 事务主动提交 | ||
| timeBetweenEvictionRunsMillis | 1 分钟（1.0.14） | 有两个含意：1) Destroy 线程会检测连贯的间隔时间，如果连贯闲暇工夫大于等于 minEvictableIdleTimeMillis 则敞开物理连贯。2) testWhileIdle 的判断根据，具体看 testWhileIdle 属性的阐明 | / | / |
| numTestsPerEvictionRun | 30 分钟（1.0.14） | 不再应用，一个 DruidDataSource 只反对一个 EvictionRun | / | / |
| minEvictableIdleTimeMillis | 连贯放弃闲暇而不被驱赶的最小工夫 | / | / | |
| connectionInitSqls | 物理连贯初始化的时候执行的 sql | / | / | |
| exceptionSorter | 依据 dbType 自动识别 | 当数据库抛出一些不可复原的异样时，摈弃连贯 | / | / |
| filters | null | 属性类型是字符串，通过别名的形式配置扩大插件，罕用的插件有：监控统计用的 filter:stat 日志用的 filter:log4j 进攻 sql 注入的 filter:wall | / | / |
| proxyFilters | null | 类型是 List<com.alibaba.druid.filter.Filter>，如果同时配置了 filters 和 proxyFilters，是组合关系，并非替换关系 | / | / |
Hikari
官网文档：https://github.com/brettwoold…
| 配置 | 缺省值 | 阐明 | 性能优化 |
|---|---|---|---|
| autoCommit | true | 主动提交从池中返回的连贯 | / |
| connectionTimeout | 30000ms | 期待来自池的连贯的最大毫秒数 | / |
| idleTimeout | 600000ms | 连贯容许在池中闲置的最长工夫【一个连贯 idle 状态的最大时长（毫秒），超时则被开释（retired），缺省:10 分钟】 | / |
| maxLifetime | 1800000ms | 池中连贯最长生命周期 | / |
| keepaliveTime | 0 (disabled) | 管制 HikariCP 尝试放弃连贯流动的频率，以避免它被数据库或网络基础设施超时。该值必须小于该 maxLifetime 值。“keepalive”只会产生在闲暇连贯上。当针对给定连贯进行“放弃连贯”的工夫到了时，该连贯将从池中删除、“ping”，而后返回到池中。’ping’ 是其中之一：调用 JDBC4isValid()办法，或执行 connectionTestQuery. 通常，池外的持续时间应该以个位数毫秒甚至亚毫秒为单位进行测量，因而应该简直没有或没有显著的性能影响。最小允许值为 30000 毫秒（30 秒），默认值：0（禁用） | / |
| connectionTestQuery | null | 如果您的驱动程序反对 JDBC4，咱们强烈建议您不要设置此属性 | 倡议不设置 |
| minimumIdle | 10 | 池中保护的最小闲暇连接数【官网举荐不设置此值，默认同最大连接数雷同】 | 官网举荐不设置此值，默认同最大连接数雷同 |
| maximumPoolSize | 10 | 池中最大连接数，包含闲置和应用中的连贯 | / |
| metricRegistry | null | 该属性容许您指定一个 Codahale / Dropwizard MetricRegistry 的实例，供池应用以记录各种指标 | / |
| healthCheckRegistry | null | 该属性容许您指定池应用的 Codahale / Dropwizard HealthCheckRegistry 的实例来报告以后衰弱信息 | / |
| poolName | HikariPool-1 | 连接池的用户定义名称，次要呈现在日志记录和 JMX 治理控制台中以辨认池和池配置 | / |
| initializationFailTimeout | 1 | 如果池无奈胜利初始化连贯，则此属性管制池是否将 fail fast | / |
| isolateInternalQueries | false | 是否在其本人的事务中隔离外部池查问，例如连贯流动测试 | / |
| allowPoolSuspension | false | 管制池是否能够通过 JMX 暂停和复原 | / |
| readOnly | false | 从池中获取的连贯是否默认处于只读模式 | / |
| registerMbeans | false | 是否注册 JMX 治理 Bean（MBeans） | / |
| catalog | null | 为反对 catalog 概念的数据库设置默认 catalog | / |
| connectionInitSql | null | 该属性设置一个 SQL 语句，在将每个新连贯创立后，将其增加到池中之前执行该语句。 | / |
| driverClassName | null | HikariCP 将尝试通过仅基于 jdbcUrl 的 DriverManager 解析驱动程序，但对于一些较旧的驱动程序，还必须指定 driverClassName | / |
| transactionIsolation | null | 管制从池返回的连贯的默认事务隔离级别 | / |
| validationTimeout | 5000 | 连贯将被测试流动的最大工夫量 | / |
| leakDetectionThreshold | 记录音讯之前连贯可能来到池的工夫量，示意可能的连贯透露 | / | |
| dataSource | null | 这个属性容许你间接设置数据源的实例被池包装，而不是让 HikariCP 通过反射来结构它 | / |
| schema | null | 该属性为反对模式概念的数据库设置默认模式 | / |
| threadFactory | null | 此属性容许您设置将用于创立池应用的所有线程的 java.util.concurrent.ThreadFactory 的实例。 | / |
| scheduledExecutor | null | 此属性容许您设置将用于各种外部打算工作的 java.util.concurrent.ScheduledExecutorService 实例 | / |
DBCP
官网文档：https://commons.apache.org/pr…
| 配置 | 缺省值 | 阐明 | 性能优化 | 备注 |
|---|---|---|---|---|
| username | null | 传递给 JDBC 驱动的用于建设连贯的用户名 | / | / |
| password | null | 传递给 JDBC 驱动的用于建设连贯的明码 | / | / |
| url | null | 传递给 JDBC 驱动的用于建设连贯的 URL | / | / |
| driverClassName | null | 应用的 JDBC 驱动的残缺无效的 java 类名 | / | / |
| connectionProperties | null | 当建设新连贯时被发送给 JDBC 驱动的连贯参数 | / | / |
| defaultAutoCommit | true | 连接池创立的连贯的默认的 auto-commit 状态 | / | / |
| defaultReadOnly | driver default | 连接池创立的连贯的默认的 read-only 状态. 如果没有设置则 setReadOnly 办法将不会被调用. (某些驱动不反对只读模式, 比方:Informix) | / | / |
| defaultCatalog | null | 连接池创立的连贯的默认的 catalog | / | / |
| defaultTransactionIsolation | driver default | 连接池创立的连贯的默认的 TransactionIsolation 状态. 上面列表当中的某一个: (参考 javadoc) | / | / |
| initialSize | 0 | 初始化连贯: 连接池启动时创立的初始化连贯数量,1.2 版本后反对 | / | / |
| maxActive | 8 | 最大流动连贯: 连接池在同一时间可能调配的最大流动连贯的数量, 如果设置为非负数则示意不限度 | / | / |
| maxIdle | 8 | 最大闲暇连贯: 连接池中答应放弃闲暇状态的最大连贯数量, 超过的闲暇连贯将被开释, 如果设置为正数示意不限度 | / | / |
| minIdle | 0 | 最小闲暇连贯: 连接池中答应放弃闲暇状态的最小连贯数量, 低于这个数量将创立新的连贯, 如果设置为 0 则不创立 | / | / |
| maxWait | 有限 | 最大等待时间: 当没有可用连贯时, 连接池期待连贯被偿还的最大工夫(以毫秒计数), 超过工夫则抛出异样, 如果设置为 - 1 示意有限期待 | / | / |
| validationQuery | null | SQL 查问, 用来验证从连接池取出的连贯, 在将连贯返回给调用者之前. 如果指定, 则查问必须是一个 SQL SELECT 并且必须返回至多一行记录 | / | / |
| testOnBorrow | true | 指明是否在从池中取出连贯前进行测验, 如果测验失败, 则从池中去除连贯并尝试取出另一个. 留神: 设置为 true 后如果要失效,validationQuery 参数必须设置为非空字符串 | / | / |
| testOnReturn | false | 指明是否在偿还到池中前进行测验留神: 设置为 true 后如果要失效,validationQuery 参数必须设置为非空字符串 | / | / |
| testWhileIdle | false | 指明连贯是否被闲暇连贯回收器 (如果有) 进行测验. 如果检测失败, 则连贯将被从池中去除. 留神: 设置为 true 后如果要失效,validationQuery 参数必须设置为非空字符串 | 倡议应用此设置，代替 testOnBorrow | / |
| timeBetweenEvictionRunsMillis | -1 | 在闲暇连贯回收器线程运行期间休眠的工夫值, 以毫秒为单位. 如果设置为非负数, 则不运行闲暇连贯回收器线程 | / | / |
| numTestsPerEvictionRun | 3 | 在每次闲暇连贯回收器线程 (如果有) 运行时查看的连贯数量 | / | / |
| minEvictableIdleTimeMillis | 1000 60 30 | 连贯在池中放弃闲暇而不被闲暇连贯回收器线程 (如果有) 回收的最小工夫值，单位毫秒 | / | / |
| poolPreparedStatements | false | 开启池的 prepared statement 池性能，当开启时, 将为每个连贯创立一个 statement 池, 并且被上面办法创立的 PreparedStatements 将被缓存起来: | / | / |
| maxOpenPreparedStatements | 0 | statement 池可能同时调配的关上的 statements 的最大数量, 如果设置为 0 示意不限度 | / | / |
| removeAbandoned | false | 标记是否删除泄露的连贯, 如果他们超过了 removeAbandonedTimout 的限度. 如果设置为 true, 连贯被认为是被泄露并且能够被删除, 如果闲暇工夫超过 removeAbandonedTimeout. 设置为 true 能够为写法蹩脚的没有敞开连贯的程序修复数据库连贯. | / | 如果开启”removeAbandoned”, 那么连贯在被认为泄露时可能被池回收. 这个机制在 (getNumIdle() < 2) and (getNumActive() > getMaxActive() – 3) 时被触发. 举例当 maxActive=20, 流动连贯为 18, 闲暇连贯为 1 时能够触发”removeAbandoned”. 然而流动连贯只有在没有被应用的工夫超过”removeAbandonedTimeout”时才被删除, 默认 300 秒. |
| removeAbandonedTimeout | 300 | 泄露的连贯能够被删除的超时值, 单位秒 | / | / |
| logAbandoned | false | 标记当 Statement 或连贯被泄露时是否打印程序的 stack traces 日志。被泄露的 Statements 和连贯的日志增加在每个连贯关上或者生成新的 Statement, 因为须要生成 stack trace。 | 会导致线程爬栈 | / |
C3P0
官网文档：https://www.mchange.com/proje…
| 配置 | 缺省值 | 阐明 | 性能优化 |
|---|---|---|---|
| acquireIncrement | 3 | 当连接池中的连贯耗尽的时，c3p0 一次同时创立的连接数 | / |
| acquireRetryAttempts | 30 | 定义在从数据库获取新连贯失败后反复尝试的次数 | / |
| acquireRetryDelay | 1000 | 两次连贯中间隔时间，单位毫秒 | / |
| autoCommitOnClose | false | 连贯敞开时默认将所有未提交的操作回滚 | / |
| automaticTestTable | null | c3p0 将建一张名为 Test 的空表，并应用其自带的查问语句进行测试。如果定义了这个参数那么属性 preferredTestQuery 将被疏忽。你不能在这张 Test 表上进行任何操作，它将只供 c3p0 测试应用 | / |
| breakAfterAcquireFailure | false | 获取连贯失败将会引起所有期待连接池来获取连贯的线程抛出异样。然而数据源仍无效保留，并在下次调用 getConnection()的时候持续尝试获取连贯。如果设为 true，那么在尝试获取连贯失败后该数据源将申明已断开并永恒敞开 | / |
| checkoutTimeout | 0 | 当连接池用完时客户端调用 getConnection()后期待获取新连贯的工夫，超时后将抛出 SQLException, 如设为 0 则无限期期待 | / |
| connectionTesterClassName | com.mchange.v2.c3p0.impl.DefaultConnectionTester | 通过实现 ConnectionTester 或 QueryConnectionTester 的类来测试连贯。类名需制订全门路 | / |
| forceIgnoreUnresolvedTransactions | false | 如果您心愿 c3p0 将事务管理留给您，并且既不提交也不回滚（也不批改 Connection autoCommit 的状态），您能够将 forceIgnoreUnresolvedTransactions 设置为 true | 作者强烈建议不应用的一个属性 |
| idleConnectionTestPeriod | 0 | 每 xxx 秒查看所有连接池中的闲暇连贯 | / |
| initialPoolSize | 3 | 初始化池的连接数，取值应在 minPoolSize 与 maxPoolSize 之间 | / |
| maxIdleTime | 0 | 最大闲暇工夫,xxx 秒内未应用则连贯被抛弃。若为 0 则永不抛弃 | / |
| minPoolSize | 3 | 连接池中保留的最小连接数 | / |
| maxPoolSize | 15 | 连接池中保留的最大连接数 | / |
| maxStatements | 0 | JDBC 的规范参数，用以控制数据源内加载的 PreparedStatements 数量。但因为预缓存的 statements 属于单个 connection 而不是整个连接池。所以设置这个参数须要思考到多方面的因素。如果 maxStatements 与 maxStatementsPerConnection 均为 0，则缓存被敞开 | / |
| maxStatementsPerConnection | 0 | maxStatementsPerConnection 定义了连接池内单个连贯所领有的最大缓存 statements 数 | / |
| numHelperThreads | 3 | 帮忙配置数据源线程池的行为。默认状况下，每个数据源只有三个关联的辅助线程，负责诸如连贯测试工作 | / |
| overrideDefaultUser | null | 当用户调用 getConnection()时使 root 用户成为去获取连贯的用户。次要用于连接池连贯非 c3p0 的数据源时 | / |
| password | null | 明码 | / |
| user | null | / | / |
| preferredTestQuery | null | 定义所有连贯测试都执行的测试语句。在应用连贯测试的状况下这个一显著进步测试速度。留神：测试的表必须在初始数据源的时候就存在 | / |
| testConnectionOnCheckout | false | 因性能耗费大请只在须要的时候应用它。如果设为 true 那么在每个 connection 提交的时候都将校验其有效性。 | 倡议应用 idleConnectionTestPeriod 或 automaticTestTable 等办法来晋升连贯测试的性能 |
markdown 编辑这么长的表格真心心累😟