在工作中常常要和各种连接池组件打交道，各种参数眼花撩乱，再也不想因为连接池配置光顾度娘了。明天总结的次要是几大罕用的数据库连接池配置，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编辑这么长的表格真心心累😟
发表回复