優化JDBC性能的三大技巧

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

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

　　正確的使用資料庫MetaData方法

　　只獲取需要的數據

　　選用最佳性能的功能

　　管理連接和更新

　　以下這些一般性原則可以幫助你解決一些公共的JDBC系統的性能問題.

　　使用資料庫Metadata方法

　　因為通過ResultSet對象生成的Metadata方法與其它的JDBCB方法相比是較慢的, 經常的使用它們將會削弱系統的的性能. 本節的指導原則將幫助你選擇和使用meatdata時優化系統性能.

　　少用Metadata方法

　　與其它的JDBC方法相比, 由ResultSet對象生成的metadata對象的相對來說是很慢的. 應用程序應該緩存從ResultSet返回的metadata信息,避免多次不必要的執行這個操作.

　　幾乎沒有哪一個JDBC應用程序不用到metadata,雖然如此,你仍可以通過少用它們來改善系統性能. 要返回JDBC規範規定的結果集的所有列信息, 一個簡單的metadata的方法調用可能會使JDBC驅動程序去執行很複雜的查詢甚至多次查詢去取得這些數據. 這些細節上的SQL語言的操作是非常消耗性能的.

　　應用程序應該緩存這些metadata信息. 例如, 程序調用一次getTypeInfo方法后就將這些程序所依賴的結果信息緩存. 而任何程序都不大可能用到這些結果信息中的所有內容,這些緩存信息應該是不難維護的.

　　避免null參數

　　在metadata的方法中使用null參數或search patterns是很耗時的. 另外, 額外的查詢會導致潛在的網路交通的增加. 應儘可能的提供一些non-null的參數給metadata方法.

　　因為metadata的方法很慢, 應用程序要儘可能有效的調用它們. 許多應用程序只傳遞少量的non-null參數給這些方法.

　　例如:

　　ResultSet WSrs = WSc.getTables (null, null, "WSTable", null);

　　應該這樣:

　　ResultSet WSrs = WSc.getTables ("cat1", "johng", "WSTable", "TABLE");

　　在第一個getTables()的調用中, 程序可能想知道表'WSTable'是否存在. 當然, JDBC驅動程序會逐個調用它們並且會解譯不同的請求. JDBC驅動程序會解譯請求為: 返回所有的表, 視圖, 系統表, synonyms, 臨時表, 或存在於任何資料庫類別任何Schema中的任何別名為'WSTable'的對象.

　　第二個getTables()的調用會得到更正確的程序想知道的內容. JDBC驅動程序會解譯這個請求為: 返回當前資料庫類別中所有存在於'johng'這個schema中的所有表.

　　很顯然, JDBC驅動程序處理第二個請求比處理第一個請求更有效率一些.

　　有時, 你所請求信息中的對象有些信息是已知的. 當調用metadata方法時, 程序能傳送到驅動程序的的任何有用信息都可以導致性能和可靠性的改善.

　　使用'啞元'(dummy)查詢確定表的特性

　　要避免使用getColumns()去確定一個表的特性. 而應該使用一個『啞元』查詢來使用getMetadata()方法.

　　請考慮這樣一個程序, 程序中要允許用戶選取一些列. 我們是否應該使用getColumns()去返回列信息給用戶還是以一個'啞元'查詢來調用getMetadata()方法呢?

　　案例 1: GetColumns 方法

　　ResultSet WSrc = WSc.getColumns (... "UnknownTable" ...);

　　// getColumns()會發出一個查詢給資料庫系統

　　. . .

　　WSrc.next();

　　string Cname = getString(4);

　　. . .

　　// 用戶必須從反覆從伺服器獲取N行數據

　　// N = UnknownTable的列數

　　案例 2: GetMetadata 方法

　　// 準備'啞元'查詢

　　PreparedStatement WSps = WSc.prepareStatement

　　("SELECT * from UnknownTable WHERE 1 = 0");

　　// 查詢從來沒有被執行,只是被預儲

　　ResultSetMetaData WSsmd=WSps.getMetaData();

　　int numcols = WSrsmd.getColumnCount();

　　...

　　int ctype = WSrsmd.getColumnType(n)

　　...

　　// 獲得了列的完整信息

　　在這兩個案例中, 一個查詢被傳送到伺服器. 但在案例1中, 查詢必須被預儲和執行, 結果的描述信息必須確定(以傳給getColumns()方法), 並且客戶端必須接收一個包含列信息的結果集. 在案例2中, 只要準備一個簡單的查詢並且只用確定結果描述信息. 很顯然, 案例2執行方式更好一些.

　　這個討論有點複雜, 讓我們考慮一個沒有本地化支持prepared statement的DBMS伺服器. 案例1的性能沒有改變, 但案例2中, 因為'啞元'查詢必須被執行而不是被預儲是的它的性能增強了一些. 因為查詢中的WHERE子句總是為FALSE, 查詢在不用存取表的數據情況的下會生成沒有數據的結果集. 在這種情況下,第二種方式當然比第一種方式好一些.

　　總而言之,總是使用ResultSet的metadata方法去獲取列信息,像列名,列的數據類型,列的數據精度和長度等. 當要求的信息無法從ResultSet的metadata中獲取時才去用getColumns()方法(像列的預設值這些信息等).

　　獲取數據

　　要有效的獲取數據,就只需返回你需要的數據, 以及很多用效的方法.本節的指導原則將幫助你使用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操作, 共有101次網路往返.其中,1次往返是預儲statement, 另外100次往返執行每個迭代.在例2中, 當在100次INSERT操作中使用addBatch()方法時, 只有兩次網路往返.1次往返是預儲statement, 另一次是執行batch命令.雖然Batch命令會用到更多的資料庫的CPU周期, 但是通過減少網路往返,性能得到提高.記住, JDBC的性能最大的增進是減少JDBC驅動與資料庫之間的網路通訊.

　　選擇合適的游標類型

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

　　對於從一個表中順序讀取所有記錄的情況來說, 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的開發者提供了靈活性, 並且使存取數據的性能得到提升.

　　選擇合適的數據類型

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

　　獲取ResultSet

　　由於資料庫系統對可滾動游標的支持有限, 許多JDBC驅動程序並沒有實現可滾動游標. 除非你確信資料庫支持可滾動游標的結果集, 否則不要調用rs.last()和rs.getRow()方法去找出數據集的最大行數.因為JDBC驅動程序模擬了可滾動游標, 調用rs.last()導致了驅動程序透過網路移到了數據集的一行.取而代之, 你可以用ResultSet遍歷一次計數或者用SELECT查詢的COUNT函數來得到數據行數.

　　通常情況下,請不要寫那種依賴於結果集行數的代碼, 因為驅動程序必須獲取所有的數據集以便知道查詢會返回多少行數據.

Tags: