作者：羅亭
email: tingluo@263.net
日期：7/30/2001 11:59:54 AM
From: www.theserverside.com -->SMTH
翻譯: SuperMMX 

     為什么 PreparedStatement 很重要, 以及怎樣"正確"使用他們. 

數據庫有一個艱苦的工作. 它們不斷地從許多客戶端讀取 SQL 查詢, 對數據進行盡 
可能高效的 查詢. 處理語句可能成為一個代價較高的操作, 但是現在數據庫都是很 
好的設計, 這樣這個困難 被減到最小. 但是這些優化需要應用程序開發者的協助, 
這篇文章給你展示一下怎樣正確使用 PreparedStatement 來漂亮地幫助數據庫執行 
這些優化. 

一個數據庫怎樣執行一條語句? 

顯然, 不要希望這里有許多細節; 我們只看一下對這篇文章比較重要的部分. 當一個 
數據庫接收 到一條語句的時候, 數據庫引擎首先解析這條語句, 查看語法錯誤. 一 
旦語句解析了, 數據庫 需要找出最有效的方法來執行這條語句. 這個計算起來代價 
很大. 數據庫檢查什么索引(如果有 的話)能有所幫助, 或者它是否能全部讀出一張 
表中所有的記錄. 數據庫根據這些關于數據庫所 存數據的統計數字來找出最好的 
辦法. 一旦制訂出查詢方案, 就可以由數據庫引擎來執行. 

需要 CPU 來產生訪問方案. 理想的情況, 如果我們把相同的語句給數據庫發送兩 
次, 我們期望 數據庫重用第一條記錄的訪問方案. 這會比第二次重新產生方案要使 
用較少的 CPU. 

語句緩沖 

數據庫可以進行調節來做語句緩沖. 通常包含一些類型的語句緩沖. 緩沖使用語句 
本身作為關鍵 字, 訪問方案和相應的語句存儲在緩沖區中. 這樣就允許數據庫引擎 
對以前執行過的語句所使用 的訪問方案進行重用. 舉個例子來說, 如果我們向數據 
庫發送這樣一條語句 "select a, b from t where c = 2", 計算好的訪問方案就放入緩沖 
區了. 如果我們以后再使用同樣的語 句, 數據庫就能重用以前的訪問方案, 這樣就 
能節省 CPU. 

但是要注意, 整條語句是一個關鍵字. 例如, 如果我們后來發送的語句是 "select a,b 
from t where c = 3", 那么就不會找出以前的訪問方案. 因為 "c=3" 和 "c=2" 是不一 
樣的. 所以, 例如: 

     For(int I = 0; I < 1000; ++I) 
{ 
PreparedStatement ps = conn.prepareStatement("select a,b from t 
where c = " + I); 
ResultSet rs = Ps.executeQuery(); 
Rs.close(); 
Ps.close(); 
} 

這里不會用到緩沖. 每次循環向數據庫發送一條不同的 SQL 語句. 每次循環都重新 
計算新的訪問 方案, 用這種方法我們會浪費大量的 CPU 周期. 但是, 看看下一個片 
段: 

PreparedStatement ps = conn.prepareStatement("select a,b from t where c 
= ?"); 
For(int I = 0; I < 1000; ++I) 
{ 
ps.setInt(1, I); 
ResultSet rs = ps.executeQuery(); 
Rs.close(); 
} 
ps.close(); 

這樣就會高效得多. 發送給數據庫的語句在 sql 中使用 '?' 符號來參數化. 這意味著 
每次循環 發送的是同一條語句, 在 "c=?" 部分帶有不同的參數. 這樣就允許數據庫 
重用語句的訪問方案, 是程序在數據庫內部運行得更高效. 這基本上能使你的程序 
運行得更快, 或者使數據庫用戶能更多 地使用 CPU. 

PreparedStatement 和 J2EE 服務器 

當我們使用 J2EE 服務器的時候, 事情會變得更加復雜. 通常情況下, 一個預先準備 
好的語句 (prepared statement) 是和一個單獨的數據庫連接相關聯的. 當連接關閉時, 
語句就被丟棄 了. 一般來說, 一個胖客戶端應用程序在得到一個數據庫連接后會一 
直保持到程序結束. 它會使用 兩種方法創建所有的語句: 急切創建(eagerly) 或者 懶 
惰創建(lazily). Eagerly是說, 當程序啟動時全部創建. Lazily是說隨用隨創建. 急切 
的方法會在程序啟動時有些延時, 但是一旦程序啟動以后, 運行很好. 懶惰的方法啟 
動很快, 但是當程序運行時, 預先準備的語句在第一次使用是創建. 這就會造成性能 
不平衡, 知道所有的 語句都準備好了, 但是最終程序會和急切方法一樣快. 哪一種 
最好要看你需要的是快速啟動還是 均衡的性能. 

一個 J2EE 應用程序所帶來的問題就是它不能像這樣工作. 它只在一個請求的生存 
時間中保持一個 連接. 這意味著在他處理每一個請求時都會重新創建語句, 就不象 
胖客戶端只創建一次, 而不是每 個請求都創建那樣有效, 

當 J2EE 服務器給你的程序一個連接時, 并不是一個真正的連接, 而是一個經過包裝 
的. 你可以 通過查看那個連接的類的名字來檢驗一下. 它不是一個數據庫的 JDBC 
連接, 是你的服務器創建 的一個類. 通常, 如果你調用一個連接的 close 方法, 那么 
jdbc 驅動程序會關閉這個連接. 我們希望的是當 J2EE 應用程序調用 close 的時候, 
連接會返回到連接池中. 我們通過設計一個 代理的 jdbc 連接類來做這些, 但看起來 
就象是實際的連接. 當我們調用這個連接的任何方法時, 代理類就會把請求前遞給 
實際的連接. 但是, 當我們調用類似 close 的方法時, 并不調用實際 連接的 close 方 
法, 只是簡單地把連接返回給連接池, 然后把代理連接標記為無效, 這樣當它 被應 
用程序重新使用時, 我們會得到異常. 

包裝是非常有用的, 因為它幫助 J2EE 應用程序服務器實現者比較聰明地加上預先 
準備語句的 支持. 當程序調用 Connection.prepareStatement 時, 由驅動程序返回一 
個 PreparedStatement 對象. 當應用程序得到它時, 保存這個句柄, 并且在請求完成 
時, 關閉 請求之前關閉這個句柄. 但是, 在連接返回到連接池之后, 以后被同樣或者 
另一個應用程序重用時, 那么, 我們就理論上希望同樣的 PreparedStatement 返回給 
應用程序. 

J2EE PreparedStatement 緩沖 

J2EE PreparedStatement 緩沖由 J2EE 服務器內部的連接池管理器使用一個緩沖區 
來 實現. J2EE 服務器在連接池中保存一個所有數據庫的預先準備語句的一個列表. 
當一個程序 調用一個連接的 prepareStatement 方法時, 服務器先檢查這個語句是否 
已經有了, 如果 是, 相應的 PreparedStatement 就在緩沖區內, 就返回給應用程序, 如 
果不是, 請求就 會傳遞給 jdbc 驅動程序, 請求/預先準備語句 對象就會加入到緩沖 
區里. 

對于每一個連接我們需要一個緩沖區, 因為這是 jdbc 驅動程序的工作要求. 任何返 
回的 preparedStatement 都是針對這個連接的. 

如果我們要利用緩沖區的優勢, 要使用和前面相同的規則. 我們需要使用參數話的 
查詢, 這樣 它們就會和已經在緩沖區的某一個匹配. 大多數應用程序服務器都允許 
你調整緩沖區的大小. 

概要 

總之, 對于預先準備語句, 我們應該使用參數化的查詢. 這樣允許數據庫重用已經存 
在的訪問 方案, 從而減輕數據庫的負擔. 這樣的緩沖區是這個數據庫范圍的, 所以 
你可以安排你所有的 應用程序, 使用相似的參數化的 SQL, 就會提高這樣的緩沖區 
方案的效率, 因為一個應用程序 可以使用另一個應用程序的語句. 一個應用服務器 
的優勢也在于此, 因為訪問數據庫的邏輯應該 集中在數據訪問層上(OR 映射, 實體 
bean 或者直接 JDBC). 

最后, 預先準備語句的正確使用也讓你利用應用程序服務器的預先準備語句的緩沖 
區的好處. 會提高你的應用程序的性能, 因為應用程序通過對以前的預先準備語句 
的重用減少 JDBC 驅動程序調用的次數. 這樣使它能和胖客戶端的效率競爭, 并且 
去掉了不能保持一個長期 連接的壞處. 

如果你使用參數化的預先準備語句, 就可以提高數據庫和你的服務器端的代碼的效 
率. 這些提高 都會允許你的應用程序提高性能.