鑒于在開發環境中，我們都使用過yml配置文件，而且我們在yml配置文件中，都加入過連接數據庫的配置，也就是配置我們的連接池，但是對于不同的數據庫，連接數據庫的 Jar 包也都是不一樣的，而且對應的配置也是不一樣的，今天阿粉就來說說這個 SpringBoot 項目中的，配置數據庫連接的各種參數以及不同的數據庫，應該是如何配置的。

MySQL的配置

我們先來看配置，然后我們再看看各項配置是什么意思。

spring:

    datasource:

        name: test

        url: jdbc:mysql://localhost:3306/test

        username: root

        password: xxx

        # 使用druid數據源

        type: com.alibaba.druid.pool.DruidDataSource

        driver-class-name: com.mysql.jdbc.Driver

        filters: stat

        maxActive: 20

        initialSize: 1

        maxWait: 60000

        minIdle: 1

        timeBetweenEvictionRunsMillis: 60000

        minEvictableIdleTimeMillis: 300000

        validationQuery: select 'x'

        testWhileIdle: true

        testOnBorrow: false

        testOnReturn: false

        poolPreparedStatements: true

上面最簡單的 name,url,username,password,type 這些阿粉也就不多說了，阿粉需要說的是剩下的參數都是代表的什么含義。

filters

這里配置的是插件,常用的插件有:

監控統計: filter:stat

日志監控: filter:log4j 或者 slf4j

防御SQL注入: filter:wall

maxActive

連接池中最多支持多少個活動會話

initialSize

啟動程序時，在連接池中初始化多少個連接

maxWait

程序向連接池中請求連接時,超過maxWait的值后，認為本次請求失敗，即連接池沒有可用連接，單位毫秒，設置-1時表示無限等待

minIdle

回收空閑連接時，將保證至少有minIdle個連接.

timeBetweenEvictionRunsMillis

檢查空閑連接的頻率，單位毫秒, 非正整數時表示不進行檢查

minEvictableIdleTimeMillis

池中某個連接的空閑時長達到 N 毫秒后, 連接池在下次檢查空閑連接時，將回收該連接,要小于防火墻超時設置net.netfilter.nf_conntrack_tcp_timeout_established的設置

validationQuery

檢查池中的連接是否仍可用的 SQL 語句,drui會連接到數據庫執行該SQL, 如果正常返回，則表示連接可用，否則表示連接不可用

testWhileIdle

當程序請求連接，連接池在分配連接時，是否先檢查該連接是否有效。(高效)

testOnBorrow

程序申請連接時,進行連接有效性檢查（低效，影響性能）

一般的話，設置均為false

testOnReturn

程序返還連接時,進行連接有效性檢查（低效，影響性能）

一般的話，設置均為false

poolPreparedStatements

緩存通過以下兩個方法發起的SQL:

public PreparedStatement prepareStatement(String sql)

public PreparedStatement prepareStatement(String sql,int resultSetType, int resultSetConcurrency)

推薦設置為true

其實有些配置，我們是非常熟悉的，為什么這么說，因為經常會有那種連接被關閉的錯誤，而這個錯誤則是有可能是參數配置不合適導致的。

配置可能引發的一些問題

其實我們比較需要注意的就是 validationQuery?這個參數,validationQuery是用來驗證數據庫連接的查詢語句，這個查詢語句必須是至少返回一條數據的SELECT語句。每種數據庫都有各自的驗證語句，阿粉也收集了幾種常見數據庫的validationQuery。

• hsqldb select 1 from INFORMATION_SCHEMA.SYSTEM_USERS
• Oracle select 1 from dual
• DB2 select 1 from sysibm.sysdummy1
• MySql select 1
• Microsoft SqlServer select1
• postgresql select version()
• ingres select 1
• derby values 1
• H2 select 1

而這個參數，一般是否執行，都是靠著 testOnBorrow? 還有 testOnReturn

testOnBorrow設置為true后如果要生效,validationQuery參數必須設置為非空字符串。

同樣的 testOnReturn 設置為true后如果要生效,validationQuery參數必須設置為非空字符串。

但是如果我們設置 testOnBorrow 為 false 的時候，也會出現一些些的問題，

假如鏈接池中的鏈接被數據庫關閉了，應用經過鏈接池getConnection時，均可能獲取到這些不可用的鏈接，且這些鏈接若是不被其余線程回收的話；它們不會被鏈接池廢除，也不會從新被建立，占用了鏈接池的名額，項目若是是服務端，數據庫連接被關閉，客戶端調用服務端就會出現大量的timeout，客戶端設置了超時時間，會主動斷開，服務端就會出現close_wait。

這也是為什么有時候在排查日志的時候，會出現一些 close_wait 的錯誤，雖然知道并不影響業務，但是日志上看著還是難受。

那么為什么還要設置成 false 呢？

因為 testOnBorrow? 能夠確保我們每次都能獲取到可用的連接，但如果設置成 true ，則每次獲取連接的時候都要到數據庫驗證連接有效性，這在高并發的時候會造成性能下降，可以將testOnBorrow設成false，testWhileIdle設置成true這樣能獲得比較好的性能。

這樣也會執行我們上面所說的 validationQuery 參數中的 SQL 來驗證連接的有效性。

這樣在每次連接失效之后，都會通過validationQuery 來進行驗證是否失效。