PreparedStatement

該 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 驅動程序調用的次數。這樣使它能和胖客戶端的效率競爭，並且去掉了不能保持一個長期連接的壞處。如果使用參數化的預先準備語句，就可以提高資料庫和伺服器端的代碼的效率。這些提高都會允許應用程序提高性能。