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

MySQL的配置

我們先來看配置，然后我們?cè)倏纯锤黜?xiàng)配置是什么意思。

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

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

filters

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

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

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

防御SQL注入: filter:wall

maxActive

連接池中最多支持多少個(gè)活動(dòng)會(huì)話

initialSize

啟動(dòng)程序時(shí)，在連接池中初始化多少個(gè)連接

maxWait

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

minIdle

回收空閑連接時(shí)，將保證至少有minIdle個(gè)連接.

timeBetweenEvictionRunsMillis

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

minEvictableIdleTimeMillis

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

validationQuery

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

testWhileIdle

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

testOnBorrow

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

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

testOnReturn

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

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

poolPreparedStatements

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

public PreparedStatement prepareStatement(String sql)

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

推薦設(shè)置為true

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

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

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

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

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

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

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

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

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

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

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

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

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