為什么數(shù)據(jù)庫連接很消耗資源？

點(diǎn)擊關(guān)注公眾號，Java干貨及時送達(dá)??

• 背景

• 分析

• 總結(jié)

開發(fā)應(yīng)用程序久了，總想刨根問底，尤其對一些有公共答案的問題。大家都能解釋，但是追根究底，都解釋不清。凡是都有為什么，而且用數(shù)字說明問題是最直觀的。

本文主要想探究一下連接數(shù)據(jù)庫的細(xì)節(jié)，尤其是在 Web 應(yīng)用中要使用數(shù)據(jù)庫來連接池，以免每次發(fā)送一次請求就重新建立一次連接。

對于這個問題，答案都是一致的，建立數(shù)據(jù)庫連接很耗時，但是這個耗時是都多少呢，又是分別在哪些方面產(chǎn)生的耗時呢？

本文以連接 MySQL 數(shù)據(jù)庫為例，因?yàn)?MySQL 數(shù)據(jù)庫是開源的，其通信協(xié)議是公開的，所以我們能夠詳細(xì)分析建立連接的整個過程。

在本文中，消耗資源的分析主要集中在網(wǎng)絡(luò)上，當(dāng)然，資源也包括內(nèi)存、CPU 等計(jì)算資源，使用的編程語言是 Java，但是不排除編程語言也會有一定的影響。

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);
//?之后程序終止，連接被強(qiáng)制關(guān)閉

在上圖中顯示的連接過程中，可以看出 MySQL 的通信協(xié)議是基于 TCP 傳輸協(xié)議的，而且該協(xié)議是二進(jìn)制協(xié)議，不是類似于 HTTP 的文本協(xié)議。

其中建立連接的過程具體如下：

• 第 1 步：建立 TCP 連接，通過三次握手實(shí)現(xiàn)。

• 第 2 步：服務(wù)器發(fā)送給客戶端「握手信息」，客戶端響應(yīng)該握手消息。

• 第 3 步：客戶端「發(fā)送認(rèn)證包」，用于用戶驗(yàn)證，驗(yàn)證成功后，服務(wù)器返回 OK 響應(yīng)，之后開始執(zhí)行命令。

用戶驗(yàn)證成功之后，會進(jìn)行一些連接變量的設(shè)置，比如字符集、是否自動提交事務(wù)等，其間會有多次數(shù)據(jù)的交互。完成了這些步驟后，才會執(zhí)行真正的數(shù)據(jù)查詢和更新等操作。

在本文的測試中，只用了 5 行代碼來建立連接，但是并沒有通過該連接去執(zhí)行任何操作，所以在程序執(zhí)行完畢之后，連接不是通過 Connection.close() 關(guān)閉的，而是由于程序執(zhí)行完畢，導(dǎo)致進(jìn)程終止，造成與數(shù)據(jù)庫的連接異常關(guān)閉，所以最后會出現(xiàn) TCP 的 RST 報文。

在這個最簡單的代碼中，沒有設(shè)置任何額外的連接屬性，所以在設(shè)置屬性上占用的時間可以認(rèn)為是最少的（其實(shí)，雖然我們沒有設(shè)置任何屬性，但是驅(qū)動仍然設(shè)置了字符集、事務(wù)自動提交等，這取決于具體的驅(qū)動實(shí)現(xiàn)），所以整個連接所使用的時間可以認(rèn)為是最少的。

但從統(tǒng)計(jì)信息中可以看出，在不包括最后?TCP?的?RST?報文時（因?yàn)樵搱笪牟恍枰?wù)器返回任何響應(yīng)），但是其中仍需在客戶端和服務(wù)器之間進(jìn)行往返「7」次，「也就是說完成一次連接，可以認(rèn)為，數(shù)據(jù)在客戶端和服務(wù)器之間需要至少往返 7 次」。

10.416042?-?10.190799?=?0.225243s?=?225.243ms

這意味著，建立一次數(shù)據(jù)庫連接需要 225ms，而這還是還可以認(rèn)為是最少的，當(dāng)然「花費(fèi)的時間可能受到網(wǎng)絡(luò)狀況、數(shù)據(jù)庫服務(wù)器性能以及應(yīng)用代碼是否高效的影響」，但是這里只是一個最簡單的例子，已經(jīng)足夠說明問題了！

由于上面是程序異常終止了，但是在正常的應(yīng)用程序中，連接的關(guān)閉一般都是通過 Connection.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();

網(wǎng)絡(luò)抓包

這樣的話，情況發(fā)生了變化，主要體現(xiàn)在與數(shù)據(jù)庫連接的斷開，如上圖：

• 第 1 步：此時處于 MySQL 通信協(xié)議階段，客戶端發(fā)送關(guān)閉連接請求，而且不用等待服務(wù)端的響應(yīng)。

• 第 2 步：TCP 斷開連接，4 次揮手完成連接斷開。

747.284311?-?747.100954?=?0.183357s?=?183.357ms

這里可能也有網(wǎng)絡(luò)狀況的影響，比上述的 225ms 少了，但是也幾乎達(dá)到了 200ms 的級別。

那么問題來了，想象一下這個場景，對于一個日活 2 萬的網(wǎng)站來說，假設(shè)每個用戶只會發(fā)送 5 個請求，那么一天就是 10 萬個請求。

100000?*?150ms?=?15000000ms?=?15000s?=?250min?=?4.17h

也就說每天花費(fèi)在建立數(shù)據(jù)庫連接上的時間已經(jīng)達(dá)到「4 個小時」，所以說數(shù)據(jù)庫連接池是必須的嘛。

而且當(dāng)日活增加時，單單使用數(shù)據(jù)庫連接池也不能完全保證你的服務(wù)能夠正常運(yùn)行，還需要考慮其他的解決方案。

例如：

• 緩存

• SQL 的預(yù)編譯

• 負(fù)載均衡

• ……

當(dāng)然這不是本文的主要內(nèi)容，本文想要闡述的核心思想只有一個，數(shù)據(jù)庫連接真的很耗時，所以不要頻繁的建立連接。

1.?8 種最坑的SQL錯誤用法，你有沒有踩過？
2.?2萬字詳解，徹底講透 全文搜索引擎 Elasticsearch
3.?Git 不能只會 pull 和 push，試試這5條提高效率的命令吧！
4.?圖解：訂單系統(tǒng)從0到1設(shè)計(jì)思路
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號并回復(fù)?Java?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
PS：因公眾號平臺更改了推送規(guī)則，如果不想錯過內(nèi)容，記得讀完點(diǎn)一下“在看”，加個“星標(biāo)”，這樣每次新文章推送才會第一時間出現(xiàn)在你的訂閱列表里。
點(diǎn)“在看”支持小哈呀，謝謝啦??