一文說清楚配置數據源的參數
鑒于在開發環境中，我們都使用過yml配置文件，而且我們在yml配置文件中，都加入過連接數據庫的配置，也就是配置我們的連接池，但是對于不同的數據庫，連接數據庫的 Jar 包也都是不一樣的，而且對應的配置也是不一樣的，今天阿粉就來說說這個 SpringBoot 項目中的，配置數據庫連接的各種參數以及不同的數據庫，應該是如何配置的。
MySQL的配置
我們先來看配置，然后我們再看看各項配置是什么意思。
上面最簡單的 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 來進行驗證是否失效。
