PreparedStatement

java.sql包中的PreparedStatement 接口繼承了Statement，並與之在兩方面有所不同：有人主張，在JDBC套用中，如果你已經是稍有水平開發者，你就應該始終以PreparedStatement代替Statement.也就是說，在任何時候都不要使用Statement。

基本介紹

• 中文名：PreparedStatement
• 平台：java
• 屬性：接口
• 特點：繼承了Statement

技術原理

該 PreparedStatement接口繼承Statement，並與之在兩方面有所不同：

PreparedStatement 實例包含已編譯的 SQL 語句。這就是使語句“準備好”。包含於 PreparedStatement 對象中的 SQL 語句可具有一個或多個 IN 參數。IN參數的值在 SQL 語句創建時未被指定。相反的，該語句為每個 IN 參數保留一個問號（“？”）作為占位符。每個問號的值必須在該語句執行之前，通過適當的setXXX 方法來提供。

由於 PreparedStatement 對象已預編譯過，所以其執行速度要快於 Statement 對象。因此，多次執行的 SQL 語句經常創建為 PreparedStatement 對象，以提高效率。

作為 Statement 的子類，PreparedStatement 繼承了 Statement 的所有功能。另外它還添加了一整套方法，用於設定傳送給資料庫以取代 IN 參數占位符的值。同時，三種方法 execute、 executeQuery 和 executeUpdate 已被更改以使之不再需要參數。這些方法的 Statement 形式（接受 SQL 語句參數的形式）不應該用於 PreparedStatement 對象。

創建對象

以下的代碼段（其中 con 是 Connection 對象）創建包含帶兩個 IN 參數占位符的 SQL 語句的 PreparedStatement 對象：

PreparedStatement pstmt = con.prepareStatement("UPDATE table4 SET m = ? WHERE x = ?");

pstmt 對象包含語句 "UPDATE table4 SET m = ? WHERE x = ?"，它已傳送給DBMS，並為執行作好了準備。

傳遞參數

在執行 PreparedStatement 對象之前，必須設定每個 ? 參數的值。這可通過調用 setXXX 方法來完成，其中 XXX 是與該參數相應的類型。例如，如果參數具有Java 類型 long，則使用的方法就是 setLong。setXXX 方法的第一個參數是要設定的參數的序數位置，第二個參數是設定給該參數的值。例如，以下代碼將第一個參數設為 123456789，第二個參數設為 100000000：

pstmt.setLong(1, 123456789);

pstmt.setLong(2, 100000000);

一旦設定了給定語句的參數值，就可用它多次執行該語句，直到調用clearParameters 方法清除它為止。在連線的預設模式下（啟用自動提交），當語句完成時將自動提交或還原該語句。

如果基本資料庫和驅動程式在語句提交之後仍保持這些語句的打開狀態，則同一個 PreparedStatement 可執行多次。如果這一點不成立，那么試圖通過使用PreparedStatement 對象代替 Statement 對象來提高性能是沒有意義的。

利用 pstmt（前面創建的 PreparedStatement 對象），以下代碼例示了如何設定兩個參數占位符的值並執行 pstmt 10 次。如上所述，為做到這一點，資料庫不能關閉 pstmt。在該示例中，第一個參數被設定為 "Hi"並保持為常數。在 for 循環中，每次都將第二個參數設定為不同的值：從 0 開始，到 9 結束。

pstmt.setString(1, "Hi");

for (int i = 0; i < 10; i++) {

pstmt.setInt(2, i);

int rowCount = pstmt.executeUpdate();

}

參數的類型

setXXX 方法中的 XXX 是 Java 類型。它是一種隱含的 JDBC 類型（一般 SQL 類型），因為驅動程式將把 Java 類型映射為相應的 JDBC 類型（遵循該 JDBCGuide中§8.6.2 “映射 Java 和 JDBC 類型”表中所指定的映射），並將該 JDBC 類型傳送給資料庫。例如，以下代碼段將 PreparedStatement 對象 pstmt 的第二個參數設定為 44，Java 類型為 short：

pstmt.setShort(2, 44);

驅動程式將 44 作為 JDBC SMALLINT 傳送給資料庫，它是 Java short 類型的標準映射。

程式設計師的責任是確保將每個 IN 參數的 Java 類型映射為與資料庫所需的 JDBC 數據類型兼容的 JDBC 類型。不妨考慮資料庫需要 JDBC SMALLINT 的情況。如果使用方法 setByte ，則驅動程式將 JDBC TINYINT 傳送給資料庫。這是可行的，因為許多資料庫可從一種相關的類型轉換為另一種類型，並且通常 TINYINT 可用於SMALLINT 適用的任何地方。

套用示例

jdbc(java database connectivity，java資料庫連線)的api中的主要的四個類之一的java.sql.statement要求開發者付出大量的時間和精力。在使用statement獲取jdbc訪問時所具有的一個共通的問題是輸入適當格式的日期和時間戳：2002-02-05 20:56 或者 02/05/02 8:56 pm。

通過使用java.sql.preparedstatement，這個問題可以自動解決。一個preparedstatement是從java.sql.connection對象和所提供的sql字元串得到的，sql字元串中包含問號（?），這些問號標明變數的位置，然後提供變數的值，最後執行語句，例如：

stringsql = "select * from people where id = ? and name = ?";

preparedstatement ps = connection.preparestatement(sql);

ps.setint(1,id);

ps.setstring(2,name);

resultset rs = ps.executequery();

使用preparedstatement的另一個優點是字元串不是動態創建的。下面是一個動態創建字元串的例子：

stringsql = "select * from people where p.i = "+id;

這允許jvm（javavirtual machine，java虛擬機）和驅動/資料庫快取語句和字元串並提高性能。preparedstatement也提供資料庫無關性。當顯示聲明的sql越少，那么潛在的sql語句的資料庫依賴性就越小。由於preparedstatement具備很多優點，開發者可能通常都使用它，只有在完全是因為性能原因或者是在一行sql語句中沒有變數的時候才使用通常的statement。一個完整的preparedstatement的例子：

package jstarproject;

import java.sql.*;

public class mypreparedstatement {

private final string db_driver="com.microsoft.jdbc.sqlserver.sqlserverdriver";

private final string url = "jdbc:microsoft:sqlserver://127.0.0.1:1433;databasename=pubs";

public mypreparedstatement()

{

}

public void query() throws sqlexception{

connection conn = this.getconnection();

string strsql = "select emp_id from employee where emp_id = ?";

preparedstatement pstmt = conn.preparestatement(strsql);

pstmt.setstring(1,"pma42628m");

resultset rs = pstmt.executequery();

while(rs.next()){

string fname = rs.getstring("emp_id");

system.out.println("the fname is " + fname);

}

rs.close();

pstmt.close();

conn.close();

}

private connection getconnection() throws sqlexception{

// class.

connection conn = null;

try {

class.forname(db_driver);

conn = drivermanager.getconnection(url,"sa","sa");

}

catch (classnotfoundexception ex) {}

return conn;

}

//main

public static void main(string[] args) throws sqlexception {

mypreparedstatement jdbctest1 = new mypreparedstatement();

jdbctest1.query();

}

}

優點

在JDBC套用中,如果你已經是稍有水平開發者,你就應該始終以PreparedStatement代替Statement.也就是說,在任何時候都不要使用Statement.
基於以下的原因:
一.代碼的可讀性和可維護性.
雖然用PreparedStatement來代替Statement會使代碼多出幾行,但這樣的代碼無論從可讀性還是可維護性上來說.都比直接用Statement的代碼高很多檔次:
stmt.executeUpdate("insertintotb_name(col1,col2,col2,col4)values('"+var1+"','"+var2+"',"+var3+",'"+var4+"')");
perstmt=con.prepareStatement("insertintotb_name(col1,col2,col2,col4)values(?,?,?,?)");
perstmt.setString(1,var1);
perstmt.setString(2,var2);
perstmt.setString(3,var3);
perstmt.setString(4,var4);
perstmt.executeUpdate();
不用我多說,對於第一種方法.別說其他人去讀你的代碼,就是你自己過一段時間再去讀,都會覺得傷心.

二.PreparedStatement盡最大可能提高性能.

每一種資料庫都會盡最大努力對預編譯語句提供最大的性能最佳化.因為預編譯語句有可能被重複調用.所以語句在被DB的編譯器編譯後的執行代碼被快取下來,那么下次調用時只要是相同的預編譯語句就不需要編譯,只要將參數直接傳入編譯過的語句執行代碼中(相當於一個涵數)就會得到執行.這並不是說只有一個Connection中多次執行的預編譯語句被快取,而是對於整個DB中,只要預編譯的語句語法和快取中匹配.那么在任何時候就可以不需要再次編譯而可以直接執行.而statement的語句中,即使是相同一操作,而由於每次操作的數據不同所以使整個語句相匹配的機會極小,幾乎不太可能匹配.比如:
insertintotb_name(col1,col2)values('11','22');
insertintotb_name(col1,col2)values('11','23');
即使是相同操作但因為數據內容不一樣,所以整個個語句本身不能匹配,沒有快取語句的意義.事實是沒有資料庫會對普通語句編譯後的執行代碼快取.
當然並不是所有預編譯語句都一定會被快取,資料庫本身會用一種策略,比如使用頻度等因素來決定什麼時候不再快取已有的預編譯結果.以保存有更多的空間存儲新的預編譯語句.
三.最重要的一點是極大地提高了安全性.
即使到目前為止,仍有一些人連基本的惡義SQL語法都不知道.
Stringsql="select*fromtb_namewherename='"+varname+"'andpasswd='"+varpasswd+"'";
如果我們把['or'1'='1]作為varpasswd傳入進來.用戶名隨意,看看會成為什麼?
select*fromtb_name='隨意'andpasswd=''or'1'='1';
因為'1'='1'肯定成立,所以可以任何通過驗證.更有甚者:
把[';droptabletb_name;]作為varpasswd傳入進來,則:
select*fromtb_name='隨意'andpasswd='';droptabletb_name;有些資料庫是不會讓你成功的,但也有很多資料庫就可以使這些語句得到執行.
而如果你使用預編譯語句.你傳入的任何內容就不會和原來的語句發生任何匹配的關係.只要全使用預編譯語句,你就用不著對傳入的數據做任何過慮.而如果使用普通的statement,有可能要對drop,;等做費盡心機的判斷和過慮.

伺服器

J2EE伺服器

PreparedStatement和J2EE伺服器，當我們使用J2EE伺服器的時候,事情會變得更加複雜.

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

一個J2EE應用程式所帶來的問題就是它不能像這樣工作.它只在一個請求的生存時間中保持一個連線.這意味著在他處理每一個請求時都會重新創建語句,就不象胖客戶端只創建一次,而不是每個請求都創建那樣有效,當J2EE伺服器給你的程式一個連線時,並不是一個真正的連線,而是一個經過包裝的.你可以通過查看那個連線的類的名字來檢驗一下.它不是一個資料庫的JDBC連線,是你的伺服器創建的一個類.通常,如果你調用一個連線的close方法,那么jdbc驅動程式會關閉這個連線.我們希望的是當J2EE應用程式調用close的時候,連線會返回到連線池中.我們通過設計一個代理的jdbc連線類來做這些,但看起來就象是實際的連線.當我們調用這個連線的任何方法時,代理類就會把請求前遞給實際的連線.

但是,當我們調用類似close的方法時,並不調用實際連線的close方法,只是簡單地把連線返回給連線池,然後把代理連線標記為無效,這樣當它被應用程式重新使用時,我們會得到異常.包裝是非常有用的,因為它幫助J2EE應用程式伺服器實現者比較聰明地加上預先準備語句的支持.當程式調用Connection.prepareStatement時,由驅動程式返回一個PreparedStatement對象.當應用程式得到它時,保存這個句柄,並且在請求完成時,關閉請求之前關閉這個句柄.但是,在連線返回到連線池之後,以後被同樣或者另一個應用程式重用時,那么,我們就理論上希望同樣的PreparedStatement返回給應用程式.

J2EEPreparedStatement緩衝J2EEPreparedStatement緩衝由J2EE伺服器內部的連線池管理器使用一個緩衝區來實現.J2EE伺服器在連線池中保存一個所有資料庫的預先準備語句的一個列表.當一個程式調用一個連線的prepareStatement方法時,伺服器先檢查這個語句是否已經有了,如果是,相應的PreparedStatement就在緩衝區內,就返回給應用程式,如果不是,請求就會傳遞給jdbc驅動程式,請求/預先準備語句對象就會加入到緩衝區里.對於每一個連線我們需要一個緩衝區,因為這是jdbc驅動程式的工作要求.　任何返回的preparedStatement都是針對這個連線的.如果我們要利用緩衝區的優勢,要使用和前面相同的規則.我們需要使用參數話的查詢,這樣它們就會和已經在緩衝區的某一個匹配.大多數應用程式伺服器都允許你調整緩衝區的大小.

總結

總之, 對於預先準備語句，我們應該使用參數化的查詢。這樣允許資料庫重用已經存在的訪問方案，從而減輕資料庫的負擔。這樣的緩衝區是這個資料庫範圍的，所以你可以安排你所有的應用程式，使用相似的參數化的 SQL，就會提高這樣的緩衝區方案的效率，因為一個應用程式 可以使用另一個應用程式的語句。一個套用伺服器的優勢也在於此，因為訪問資料庫的邏輯應該集中在數據訪問層上(OR映射，實體bean或者直接JDBC)，最後， 預先準備語句的正確使用也讓你利用應用程式伺服器的預先準備語句的緩衝區的好處。提高你的應用程式的性能，因為應用程式通過對以前的預先準備語句的重用減少 JDBC 驅動程式調用的次數。這樣使它能和胖客戶端的效率競爭，並且去掉了不能保持一個長期連線的壞處。如果你使用參數化的預先準備語句， 就可以提高資料庫和你的伺服器端的代碼的效率。這些提高都會允許你的應用程式提高性能。