優化JDBC性能的一些基本原則

開發一個注重性能的JDBC應用程序不是一件容易的事. 當你的代碼運行很慢的時候JDBC驅動程序並不會拋出異常告訴你。

本系列的性能提示將爲改善JDBC應用程序的性能介紹一些基本的指導原則，這其中的原則已經被許多現有的JDBC應用程序編譯運行並驗證過。 這些指導原則包括:

正確的使用數據庫MetaData方法
只獲取須要的數據
選用最佳性能的功能
管理鏈接和更新


要有效的獲取數據，就只需返回你須要的數據, 以及不少用效的方法。本節的指導原則將幫助你使用JDB獲取數據時優化系統性能。

獲取長數據

如非必要, 應用程序不該請求長的數據, 由於長的數據經過網絡傳輸會很是慢和消耗資源。

大多數用戶並不想看到大堆的數據。若是用戶不想處理這些長數據, 那麼程序應可以再次查詢數據庫, 在SELECT子句中指定須要的列名。這種方式容許通常用戶獲取結果集而不用消耗昂貴的網絡流量。

雖然最好的方式是不要將長數據包括在SELECT子句的列名中，但仍是有一些應用程序在發送查詢給JDBC驅動程序時並無在SELECT子句中明確 指出列名 (確切一點, 有些程序發送這樣的查詢： select * from <table name> ...). 若是SELECT子句的列名中包含長數據, 許多JDBC驅動程序必須在查詢時從新獲取數據, 甚至在ResultSet中這些長數據並無被程序用到. 在可能狀況下，開發者應該試着去實現一種不需獲取全部列數據的方法.

例如，看如下的JDBC代碼:

ResultSet rs = stmt.executeQuery (
"select * from Employees where SSID = '999-99-2222'");
rs.next();
string name = rs.getString (4);
要記住JDBC驅動程序沒有知覺，當查詢被執行時它不知道哪些列是程序所要的，驅動程序只知道應用程序能請求任意的列。當JDBC驅動程序處理 rs.next() 請求時, 它可能會跨過網絡從數據庫服務器至少返回一行結果。 在這種狀況下, 每一個結果行會包含全部的列數據– 若是Employees表有一列包含員工相片的話它也會被包含在結果裏面。限制SELECT子句的列名列表而且只包含有用的列名，會減小網絡流量及更快的 查詢性能。

另外，雖然getClob()和getBlob()方法能夠容許應用程序去如何控制獲取長數據, 但開發者必須認識到在許多狀況下, JDBC驅動程序缺乏真正的LOB定位器的支持。像這種狀況下，在暴露getClob和getBlob方法給開發者以前驅動程序必須通過網絡獲取全部的長 數據。

減小獲取的數據量

有時必需要獲取長數據. 這時, 要注意的是大多數用戶並不想在屏幕上看到100k甚至更多的文字。

要減小網絡交通和改善性能, 經過調用setMaxRows(), SetMaxFieldSize及SetFetchSize()方法, 你能夠減小取獲取的數據量。另外一種方式是減小數據的列數。若是驅動程序容許你定義packet的大小, 使用最小的packet尺寸會適合你的須要。

記住: 要當心的返回只有你須要的行和列數據。當你只須要2列數據而你卻返回的5列數據時，性能會下降 – 特別是不須要的行中包含有長數據時。

選擇合適的數據類型

接收和發送某些數據可能代價昂貴. 當你設計一個schema時, 應選擇能被最有效地處理的數據類型。 例如, 整型數就比浮點數或實數處理起來要快一些. 浮點數的定義是按照數據庫的內部規定的格式, 一般是一種壓縮格式. 數據必須被 解壓和轉換到另外種格式, 這樣它才能被數據的協議處理。

獲取ResultSet

因爲數據庫系統對可滾動光標的支持有限, 許多JDBC驅動程序並無實現可滾動光標. 除非你確信數據庫支持可滾動光標的結果集, 不然不要調用rs.last()和rs.getRow()方法去找出數據集的最大行數。由於JDBC驅動程序模擬了可滾動光標, 調用rs.last()致使了驅動程序透過網絡移到了數據集的最後一行。取而代之, 你能夠用ResultSet遍歷一次計數或者用SELECT查詢的COUNT函數來獲得數據行數。

一般狀況下，請不要寫那種依賴於結果集行數的代碼, 由於驅動程序必須獲取全部的數據集以便知道查詢。

選用JDBC對象和方法

本節的指導原則將幫助你在選用JDBC的對象和方法時哪些會有最好的性能。

在存儲過程當中使用參數標記做爲參數

當調用存儲過程時, 應老是使用參數標記(?)來代替字面上的參數。JDBC驅動能調用數據庫的存儲過程, 也能被其它的SQL查詢執行, 或者直接經過遠程進程調用(RPC)的方式執行。當你將存儲過程做爲一個SQL查詢執行時, 數據庫要解析這個查詢語句, 校驗參數並將參數轉換爲正確的數據類型。

要記住, SQL語句老是以字符串的形式送到數據庫, 例如, 「{call getCustName (12345)}」。在這裏, 即便程序中將參數做爲整數賦給了getSustName, 而實現上參數仍是以字符串的形式傳給了服務器。數據庫會解析這個SQL查詢, 而且根據metadata來決定存儲過程的參數類型, 而後分解出參數"12345", 而後在最終將存儲過程做爲一個SQL查詢執行以前將字串'12345’轉換爲整型數。

按RPC方式調用時, 以前那種SQL字符串的方式要避免使用。取而代之, JDBC驅動會構造一個網絡packet, 其中包含了本地數據類型的參數，而後執行遠程調用。

案例 1

在這個例子中, 存儲過程不能最佳的使用RPC。數據庫必須將這做爲一個普通的語言來進行解析，校驗參數類型並將參數轉換爲正確的數據類型，最後才執行這個存儲過程。

CallableStatement cstmt = conn.prepareCall (
"{call getCustName (12345)}");
ResultSet rs = cstmt.executeQuery ();
案例 2

在這個例子中, 存儲過程能最佳的執行RPC。由於程序避免了字面的的參數, 使用特殊的參數來調用存儲過程, JDBC驅動能最好以RPC方式直接來執行存儲過程。SQL語言上的處理在這裏被避免而且執行也獲得很大的改善。

CallableStatement cstmt - conn.prepareCall (
"{call getCustName (?)}");
cstmt.setLong (1,12345);
ResultSet rs = cstmt.executeQuery();
使用Statement而不是PreparedStatement對象

JDBC驅動的最佳化是基於使用的是什麼功能. 選擇PreparedStatement仍是Statement取決於你要怎麼使用它們。對於只執行一次的SQL語句選擇Statement是最好的. 相反, 若是SQL語句被屢次執行選用PreparedStatement是最好的。

PreparedStatement的第一次執行消耗是很高的。它的性能體如今後面的重複執行。例如, 假設我使用Employee ID, 使用prepared的方式來執行一個針對Employee表的查詢。JDBC驅動會發送一個網絡請求到數據解析和優化這個查詢，而執行時會產生另外一個網 絡請求。在JDBC驅動中，減小網絡通信是最終的目的。若是個人程序在運行期間只須要一次請求, 那麼就使用Statement. 對於Statement, 同一個查詢只會產生一次網絡到數據庫的通信。

對於使用PreparedStatement池的狀況下, 本指導原則有點複雜。當使用PreparedStatement池時, 若是一個查詢很特殊, 而且不太會再次執行到, 那麼可使用Statement。若是一個查詢不多會被執行,但鏈接池中的Statement池可能被再次執行, 那麼請使用PreparedStatement。在不是Statement池的一樣狀況下, 請使用Statement。

使用PreparedStatement的Batch功能

Update大量的數據時, 先Prepare一個INSERT語句再屢次的執行, 會致使不少次的網絡鏈接。要減小JDBC的調用次數改善性能, 你可使用PreparedStatement的AddBatch()方法一次性發送多個查詢給數據庫. 例如, 讓咱們來比較一下下面的例子。

例 1: 屢次執行Prepared Statement

PreparedStatement ps = conn.prepareStatement(
"INSERT into employees values (?, ?, ?)");

for (n = 0; n < 100; n  ) {

ps.setString(name[n]);
ps.setLong(id[n]);
ps.setInt(salary[n]);
ps.executeUpdate();
}
例 2: 使用Batch

PreparedStatement ps = conn.prepareStatement(
"INSERT into employees values (?, ?, ?)");

for (n = 0; n < 100; n  ) {

ps.setString(name[n]);
ps.setLong(id[n]);
ps.setInt(salary[n]);
ps.addBatch();
}
ps.executeBatch();
在例 1中, PreparedStatement被用來屢次執行INSERT語句。在這裏, 執行了100次INSERT操做,  7 1 2
3
4 8 : 選擇合適的光標類型

選擇適用的光標類型以最大限度的適用你的應用程序. 本節主要討論三種光標類型的性能問題。

對於從一個表中順序讀取全部記錄的狀況來講, Forward-Only型的光標提供了最好的性能. 獲取表中的數據時, 沒有哪一種方法比使用Forward-Only型的光標更快. 但無論怎樣, 當程序中必須按無次序的方式處理數據行時, 這種光標就沒法使用了。

對於程序中要求與數據庫的數據同步以及要可以在結果集中先後移動光標, 使用JDBC的Scroll-Insensitive型光標是較理想的選擇。此類型的光標在第一次請求時就獲取了全部的數據(當JDBC驅動採用 'lazy'方式獲取數據時或許是不少的而不是所有的數據)而且儲存在客戶端。所以, 第一次請求會很是慢, 特別是請求長數據時會理嚴重。而接下來的請求並不會形成任何網絡往返(當使用'lazy'方法時或許只是有限的網絡交通) 而且處理起來很快。由於第一次請求速度很慢, Scroll-Insensitive型光標不該該被使用在單行數據的獲取上。當有要返回長數據時, 開發者也應避免使用Scroll-Insensitive型光標, 由於這樣可能會形成內存耗盡。有些Scroll-Insensitive型光標的實現方式是在數據庫的臨時表中緩存數據來避免性能問題, 但多數仍是將數據緩存在應用程序中。

Scroll-Sensitive型光標, 有時也稱爲Keyset-Driven光標, 使用標識符, 像數據庫的ROWID之類。當每次在結果集移動光標時, 會從新該標識符的數據。由於每次請求都會有網絡往返, 性能可能會很慢。不管怎樣, 用無序方式的返回結果行對性能的改善是沒有幫助的。

如今來解釋一下這個, 來看這種狀況：一個程序要正常的返回1000行數據到程序中，在執行時或者第一行被請求時, JDBC驅動不會執行程序提供的SELECT語句，相反,它會用鍵標識符來替換SELECT查詢, 例如, ROWID。而後修改過的查詢都會被驅動程序執行，跟着會從數據庫獲取全部1000個鍵值。每一次對一行結果的請求都會使JDBC驅動直接從本地緩存中找 到相應的鍵值, 而後構造一個包含了'WHERE ROWID=？'子句的最佳化查詢, 再接着執行這個修改過的查詢, 最後從服務器取得該數據行。

當程序沒法像Scroll-Insensitive型光標同樣提供足夠緩存時, Scroll-Sensitive型光標能夠被替代用來做爲動態的可滾動的光標。

使用有效的getter方法

JDBC提供多種方法從ResultSet中取得數據, 像getInt(), getString(), 和getObject()等等。而getObject()方法是最泛化了的, 提供了最差的性能。 這是由於JDBC驅動必須對要取得的值的類型做額外的處理以映射爲特定的對象. 因此就對特定的數據類型使用相應的方法。

要更進一步的改善性能, 應在取得數據時提供字段的索引號, 例如, getString(1), getLong(2), 和getInt(3)等來替代字段名。若是沒有指定字段索引號, 網絡交通不會受影響, 但會使轉換和查找的成本增長. 例如, 假設你使用getString("foo") ... JDBC驅動可能會將字段名轉爲大寫(若是須要), 而且在到字段名列表中逐個比較來找到"foo"字段。若是能夠, 直接使用字段索引, 將爲你節省大量的處理時間。

例如, 假設你有一個100行15列的ResultSet, 字段名不包含在其中. 你感興趣的是三個字段 EMPLOYEENAME (字串型), EMPLOYEENUMBER (長整型), 和SALARY (整型). 若是你指定getString(「EmployeeName」), getLong(「EmployeeNumber」), 和getInt(「Salary」), 查詢旱每一個字段名必須被轉換爲metadata中相對應的大小寫, 而後才進行查找. 若是你使用getString(1), getLong(2), 和getInt(15). 性能就會有顯著改善。

獲取自動生成的鍵值 有許多數據庫提供了隱藏列爲表中的每行記錄分配一個惟一鍵值。很典型, 在查詢中使用這些字段類型是取得記錄值的最快的方式, 由於這些隱含列一般反應了數據在磁盤上的物理位置。在JDBC3.0以前, 應用程序只可在插入數據後經過當即執行一個SELECT語句來取得隱含列的值。 例如: //插入行 int rowcount = stmt.executeUpdate ( "insert into LocalGeniusList (name) values ('Karen')"); // 如今爲新插入的行取得磁盤位置 - rowid ResultSet rs = stmt.executeQuery ( "select rowid from LocalGeniusList where name = 'Karen'"); 這種取得隱含列的方式有兩個主要缺點。第一, 取得隱含列是在一個獨立的查詢中, 它要透過網絡送到服務器後再執行。第二, 由於不是主鍵, 查詢條件可能不是表中的惟一性ID。在後面一個例子中, 可能返回了多個隱含列的值, 程序沒法知道哪一個是最後插入的行的值。 (譯者：因爲不一樣的數據庫支持的程度不一樣，返回rowid的方式各有差別。在SQL Server中，返回最後插入的記錄的id能夠用這樣的查詢語句：SELECT @IDENTITY ) JDBC3.0規範中的一個可選特性提供了一種能力, 能夠取得剛剛插入到表中的記錄的自動生成的鍵值。 例如: int rowcount = stmt.executeUpdate ( "insert into LocalGeniusList (name) values ('Karen')", // 插入行並返回鍵值 Statement.RETURN_GENERATED_KEYS); ResultSet rs = stmt.getGeneratedKeys (); // 獲得生成的鍵值 如今, 程序中包含了一個惟一性ID, 能夠用來做爲查詢條件來快速的存取數據行, 甚至於表中沒有主鍵的狀況也能夠。 這種取得自動生成的鍵值的方式給JDBC的開發者提供了靈活性, 而且使存取數據的性能獲得提高.