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

MySQL的配置

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

spring:

    datasource:

        name: test

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

        username: root

        password: xxx

        # 使用druid數(shù)據(jù)源

        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 這些阿粉也就不多說了，阿粉需要說的是剩下的參數(shù)都是代表的什么含義。

filters

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

監(jiān)控統(tǒng)計: filter:stat

日志監(jiān)控: filter:log4j 或者 slf4j

防御SQL注入: filter:wall

maxActive

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

initialSize

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

maxWait

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

minIdle

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

timeBetweenEvictionRunsMillis

檢查空閑連接的頻率，單位毫秒, 非正整數(shù)時表示不進(jìn)行檢查

minEvictableIdleTimeMillis

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

validationQuery

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

testWhileIdle

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

testOnBorrow

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

一般的話，設(shè)置均為false

testOnReturn

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

一般的話，設(shè)置均為false

poolPreparedStatements

緩存通過以下兩個方法發(fā)起的SQL:

public PreparedStatement prepareStatement(String sql)

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

推薦設(shè)置為true

其實有些配置，我們是非常熟悉的，為什么這么說，因為經(jīng)常會有那種連接被關(guān)閉的錯誤，而這個錯誤則是有可能是參數(shù)配置不合適導(dǎo)致的。

配置可能引發(fā)的一些問題

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

而這個參數(shù)，一般是否執(zhí)行，都是靠著 testOnBorrow? 還有 testOnReturn

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

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

但是如果我們設(shè)置 testOnBorrow 為 false 的時候，也會出現(xiàn)一些些的問題，

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

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

那么為什么還要設(shè)置成 false 呢？

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

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

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