JDBC優化策略總結

相比Hibernate、iBatis、DBUtils等，理論上JDBC的性能都超過它們。JDBC提供更底層更精細的數據訪問策略，這是Hibernate等框架所不具備的。

在一些高性能的數據操作中，越高級的框架越不適合使用。這里是我在開發中對JDBC使用過程中一些優化經驗總結。

1、選擇純Java的JDBC驅動。

2、使用連接池--使用一個“池”來管理JDBC連接，并精心調試池配置的參數，目前可用的數據庫連接池很多很多。
如何配置合適的參數呢，需要的是測試，而不是感覺。

3、重用Connection--最大限度使用每個數據庫連接，得到了就不要輕易“丟棄”。

有時候在一個過程中，會多次操作數據庫，而僅僅需要一個連接就夠了，沒必用一次就獲取一個連接，用完后關閉或者入池。這樣會增加“池”管理的成本，千萬別以為你用了“池”就可以隨便申請和歸還連接，都是有代價的。

如果是一個龐大循環塊中操作數據庫，更應該注意此問題！

除此之外，還應該對連接進行密集使用，盡可能晚的打開，并可能早的關閉。比如，你一個業務中有N多的操作，數據庫操作穿插在其中，而其他的業務處理操作時間很長，那么使用一個連接處理這些操作是有問題的。

這會導致長期占用連接，給數據庫帶來壓力。

4、重用Statement/PreparedStatement--對于一些預定義SQL，設置為靜態常量，并盡可能重用預定義SQL產生的PreparedStatement對象。對于多次使用一種模式的SQL，使用預定義SQL可以獲取更好的性能。

對于Statement對象，可以反復的重用，每次都可以接收不同的SQL語句，而對于PreparedStatement則不可以，因為預定義SQL在定義PreparedStatement對象時候已經確定了，但是如果sql語句不變，則可以調用clearParameters()來達到從用目的，如果sql語句發生變化，也可以從用變量名。

5、使用批處理SQL。

6、優化結果集ResultSet--查詢時候，返回的結果集有不同的類型，優先選擇只讀結果集、不可滾動的屬性。

這里是很容易出現問題的地方：

java.sql.ResultSet

static int CLOSE_CURSORS_AT_COMMIT
該常量指示調用 Connection.commit 方法時應該關閉 ResultSet 對象。
static int CONCUR_READ_ONLY
該常量指示不可以更新的 ResultSet 對象的并發模式。
static int CONCUR_UPDATABLE
該常量指示可以更新的 ResultSet 對象的并發模式。
static int FETCH_FORWARD
該常量指示將按正向（即從第一個到最后一個）處理結果集中的行。
static int FETCH_REVERSE
該常量指示將按反向（即從最后一個到第一個）處理結果集中的行處理。
static int FETCH_UNKNOWN
該常量指示結果集中的行的處理順序未知。
static int HOLD_CURSORS_OVER_COMMIT
該常量指示調用 Connection.commit 方法時不應關閉 ResultSet 對象。
static int TYPE_FORWARD_ONLY
該常量指示指針只能向前移動的 ResultSet 對象的類型。
static int TYPE_SCROLL_INSENSITIVE
該常量指示可滾動但通常不受其他的更改影響的 ResultSet 對象的類型。
static int TYPE_SCROLL_SENSITIVE
該常量指示可滾動并且通常受其他的更改影響的 ResultSet 對象的類型。

說明下：

結果集分兩種類型：只讀和可更改，只讀的話，更省內存，查詢的結果集不能更改。如果結果集在查詢后，更改了值又要保存，則使用可更改結果集。

結果集的游標也有兩種類型：如果沒必要讓游標自由滾動，則選擇單方向移動的游標類型。

對于是否并發操作：如果不需要考慮線程安全，則選擇忽略并發的結果集類型，否則選擇并發安全的類型。

另外，還要控制結果的大小，幾乎所有的數據庫都有查詢記錄條數控制的策略，可以海量數據進行分批處理，一次一批，這樣不至于把系統搞死。

7、事物優化--如果數據庫不支持事物，就不要寫回滾代碼，如果不考慮事物，就不要做事務的控制。

8、安全優化--管理好你的Connection對象，在異常時候能“入池”或者關閉。因此應該將Connection釋放的代碼寫在異常處理的finally塊中。

9、異常處理優化--不要輕易吞噬SQLException，對于DAO、Service層次的數據訪問，一般在DAO中跑出異常，在Service中處理異常。但DAO中也可以處理異常，并做轉義拋出，不要隨便拋出RuntimeExeption，因為這是JVM拋出的，不需要你可以去拋出，因為RuntimeException往往會導致系統掛起。

10、代碼高層優化--在以上的基礎上，優化封裝你的數據訪問方式，盡可能讓代碼簡潔好維護，如果你還覺得性能不行，那就該從整個系統角度考慮優化了，比如加上緩存服務器，集群、負載均衡、優化數據庫服務器等等，以獲取更好的系能。