背景

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

本文主要想探究一下連接數據庫的細節，尤其是在 Web 應用中要使用數據庫來連接池，以免每次發送一次請求就重新建立一次連接。

對于這個問題，答案都是一致的，建立數據庫連接很耗時，但是這個耗時是都多少呢，又是分別在哪些方面產生的耗時呢?

分析

本文以連接 MySQL 數據庫為例，因為 MySQL 數據庫是開源的，其通信協議是公開的，所以我們能夠詳細分析建立連接的整個過程。

在本文中，消耗資源的分析主要集中在網絡上，當然，資源也包括內存、CPU 等計算資源，使用的編程語言是 Java，但是不排除編程語言也會有一定的影響。

首先先看一下連接數據庫的 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);
// 之后程序終止，連接被強制關閉

然后通過「Wireshark」分析整個連接的建立過程，如下：

Wireshark 抓包

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

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

• 第 1 步：建立 TCP 連接，通過三次握手實現。
• 第 2 步：服務器發送給客戶端「握手信息」，客戶端響應該握手消息。
• 第 3 步：客戶端「發送認證包」，用于用戶驗證，驗證成功后，服務器返回 OK 響應，之后開始執行命令。

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

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

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

但從統計信息中可以看出，在不包括最后 TCP 的 RST 報文時(因為該報文不需要服務器返回任何響應)，但是其中仍需在客戶端和服務器之間進行往返「7」次，「也就是說完成一次連接，可以認為，數據在客戶端和服務器之間需要至少往返 7 次」。

從時間上來看，從開始 TCP 的三次握手，到最終連接強制斷開為止(不包括最后的 RST 報文)，總共花費了：

10.416042 - 10.190799 = 0.225243s = 225.243ms

這意味著，建立一次數據庫連接需要 225ms，而這還是還可以認為是最少的，當然「花費的時間可能受到網絡狀況、數據庫服務器性能以及應用代碼是否高效的影響」，但是這里只是一個最簡單的例子，已經足夠說明問題了!

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

網絡抓包

這樣的話，情況發生了變化，主要體現在與數據庫連接的斷開，如上圖：

• 第 1 步：此時處于 MySQL 通信協議階段，客戶端發送關閉連接請求，而且不用等待服務端的響應。
• 第 2 步：TCP 斷開連接，4 次揮手完成連接斷開。

這里是完整地完成了從數據庫連接的建立到關閉，整個過程花費了：

747.284311 - 747.100954 = 0.183357s = 183.357ms

這里可能也有網絡狀況的影響，比上述的 225ms 少了，但是也幾乎達到了 200ms 的級別。

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

對于建立數據庫連接，我們保守一點計算為 150ms 好了，那么一天當中花費在建立數據庫連接的時間有(還不包括執行查詢和更新操作)：

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

也就說每天花費在建立數據庫連接上的時間已經達到「4 個小時」，所以說數據庫連接池是必須的嘛。

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

例如：

• 緩存
• SQL 的預編譯
• 負載均衡
• ……

總結

當然這不是本文的主要內容，本文想要闡述的核心思想只有一個，數據庫連接真的很耗時，所以不要頻繁的建立連接。

文章來源：http://u6v.cn/5MFrzY