點擊上方“Java基基”，選擇“設(shè)為星標(biāo)”
做積極的人，而不是積極廢人！
每天14:00更新文章，每天掉億點點頭發(fā)...
源碼精品專欄
?
開發(fā)應(yīng)用程序久了，總想刨根問底，尤其對一些有公共答案的問題。大家都能解釋，但是追根究底，都解釋不清。凡是都有為什么，而且用數(shù)字說明問題是最直觀的。
?
本文主要想探究一下連接數(shù)據(jù)庫的細節(jié)，尤其是在Web應(yīng)用中要使用數(shù)據(jù)庫來連接池，以免每次發(fā)送一次請求就重新建立一次連接。對于這個問題，答案都是一致的，建立數(shù)據(jù)庫連接很耗時，但是這個耗時是都多少呢，又是分別在哪些方面產(chǎn)生的耗時呢？
本文以連接MySQL數(shù)據(jù)庫為例常用數(shù)據(jù)庫連接方式url，因為MySQL數(shù)據(jù)庫是開源的，其通信協(xié)議是公開的，所以我們能夠詳細分析建立連接的整個過程。
?
在本文中，消耗資源的分析主要集中在網(wǎng)絡(luò)上，當(dāng)然，資源也包括內(nèi)存、CPU等計算資源，使用的編程語言是Java，但是不排除編程語言也會有一定的影響。
?
首先先看一下連接數(shù)據(jù)庫的Java代碼，如下：
Class.forName("com.mysql.jdbc.Driver");
String?name?=?"xttblog2";
String?password?=?"123456";
String?url?=?"jdbc:mysql://172.16.100.131:3306/xttblog2";
Connection?conn?=?DriverManager.getConnection(url,?name,?password);
//?之后程序終止，連接被強制關(guān)閉
然后通過「」 分析整個連接的建立過程，如下：
抓包
在上圖中顯示的連接過程中，可以看出MySQL的通信協(xié)議是基于TCP傳輸協(xié)議的，而且該協(xié)議是二進制協(xié)議，不是類似于HTTP的文本協(xié)議，其中建立連接的過程具體如下：
用戶驗證成功之后，會進行一些連接變量的設(shè)置，比如字符集、是否自動提交事務(wù)等，其間會有多次數(shù)據(jù)的交互。完成了這些步驟后，才會執(zhí)行真正的數(shù)據(jù)查詢和更新等操作。
在本文的測試中，只用了5行代碼來建立連接，但是并沒有通過該連接去執(zhí)行任何操作，所以在程序執(zhí)行完畢之后，連接不是通過.close()關(guān)閉的，而是由于程序執(zhí)行完畢，導(dǎo)致進程終止常用數(shù)據(jù)庫連接方式url，造成與數(shù)據(jù)庫的連接異常關(guān)閉，所以最后會出現(xiàn)TCP的RST報文。在這個最簡單的代碼中，沒有設(shè)置任何額外的連接屬性，所以在設(shè)置屬性上占用的時間可以認為是最少的（其實，雖然我們沒有設(shè)置任何屬性，但是驅(qū)動仍然設(shè)置了字符集、事務(wù)自動提交等，這取決于具體的驅(qū)動實現(xiàn)），所以整個連接所使用的時間可以認為是最少的。但從統(tǒng)計信息中可以看出，在不包括最后TCP的RST 報文時（因為該報文不需要服務(wù)器返回任何響應(yīng)），但是其中仍需在客戶端和服務(wù)器之間進行往返「7」 次，「也就是說完成一次連接，可以認為，數(shù)據(jù)在客戶端和服務(wù)器之間需要至少往返7次」 ，從時間上來看，從開始TCP的三次握手，到最終連接強制斷開為止（不包括最后的RST報文），總共花費了：
10.416042?-?10.190799?=?0.225243s?=?**225.243ms**！！！
這意味著，建立一次數(shù)據(jù)庫連接需要225ms，而這還是還可以認為是最少的，當(dāng)然「花費的時間可能受到網(wǎng)絡(luò)狀況、數(shù)據(jù)庫服務(wù)器性能以及應(yīng)用代碼是否高效的影響」 ，但是這里只是一個最簡單的例子，已經(jīng)足夠說明問題了！
由于上面是程序異常終止了，但是在正常的應(yīng)用程序中，連接的關(guān)閉一般都是通過.close()完成的，代碼如下：
Class.forName("com.mysql.jdbc.Driver");
String?name?=?"shine_user";
String?password?=?"123";
String?url?=?"jdbc:mysql://172.16.100.131:3306/clever_mg_test";
Connection?conn?=?DriverManager.getConnection(url,?name,?password);
conn.close();
這樣的話，情況發(fā)生了變化，主要體現(xiàn)在與數(shù)據(jù)庫連接的斷開，如下圖：
網(wǎng)絡(luò)抓包
這里是完整地完成了從數(shù)據(jù)庫連接的建立到關(guān)閉，整個過程花費了：
747.284311?-?747.100954?=?0.183357s?=?183.357ms
這里可能也有網(wǎng)絡(luò)狀況的影響，比上述的225ms少了，但是也幾乎達到了200ms的級別。
那么問題來了，想象一下這個場景，對于一個日活2萬的網(wǎng)站來說，假設(shè)每個用戶只會發(fā)送5個請求，那么一天就是10萬個請求，對于建立數(shù)據(jù)庫連接，我們保守一點計算為150ms好了，那么一天當(dāng)中花費在建立數(shù)據(jù)庫連接的時間有（還不包括執(zhí)行查詢和更新操作）：
100000?*?150ms?=?15000000ms?=?15000s?=?250min?=?4.17h
也就說每天花費在建立數(shù)據(jù)庫連接上的時間已經(jīng)達到「4個小時」 ，所以說數(shù)據(jù)庫連接池是必須的嘛，而且當(dāng)日活增加時，單單使用數(shù)據(jù)庫連接池也不能完全保證你的服務(wù)能夠正常運行，還需要考慮其他的解決方案：
當(dāng)然這不是本文的主要內(nèi)容，「本文想要闡述的核心思想只有一個，數(shù)據(jù)庫連接真的很耗時，所以不要頻繁的建立連接」 。
歡迎加入我的知識星球，一起探討架構(gòu)，交流源碼。加入方式，長按下方二維碼噢：
已在知識星球更新源碼解析如下：
最近更新《芋道 2.X 入門》系列，已經(jīng) 101 余篇，覆蓋了、Redis、、ES、分庫分表、讀寫分離、、、權(quán)限、、Dubbo、、、Kafka、性能測試等等內(nèi)容。
提供近 3W 行代碼的 示例，以及超 6W 行代碼的電商微服務(wù)項目。