jdbc測(cè)試mysql數(shù)據(jù)庫sql預(yù)解析(綁定變量)

用習(xí)慣了oracle，學(xué)習(xí)mysql，想測(cè)試一下mysql綁定變量的效果。以前看網(wǎng)上介紹大部份都說mysql沒有sql共享池的概念，所以也不存在sql預(yù)解析或綁定變量的說法。

今天測(cè)試了一下(通過網(wǎng)絡(luò)抓包、查看服務(wù)器端sql日志及分析源碼等方法)，發(fā)現(xiàn)mysql還是有sql預(yù)解析的實(shí)現(xiàn)。

服務(wù)器端是mysql 5.1.58(win32)，用jdbc(5.1.18)做客戶端，默認(rèn)的連接方式是不會(huì)有sql預(yù)解析效果，即使我們用PreparedStatement對(duì)象也差不多，它只是把SQL和變量拼接成一個(gè)完整的SQL發(fā)送給服務(wù)器，如下代碼：

PreparedStatement pstmt = conn.prepareStatement("select * from t1 where c1=?");

pstmt.setString(1, "abc");

pstmt.execute();

實(shí)際上不會(huì)有預(yù)解析的過程，而是經(jīng)過簡單的拼接，把如下SQL發(fā)送給服務(wù)器

select * from t1 where c1='abc' 要實(shí)現(xiàn)預(yù)解析的效果，我們必須設(shè)置jdbc Connection的參數(shù)useServerPrepStmts=true，再使用PreparedStatement后就OK了，創(chuàng)建PreparedStatement時(shí)客戶端先把"select * from t1 where c1=?"發(fā)送到服務(wù)器端預(yù)解析，execute時(shí)只是把變量傳送到服務(wù)器執(zhí)行。

mysql服務(wù)器的sql語句緩存可以通過狀態(tài)變量Prepared_stmt_count查看

mysql> show status like 'Prepared_stmt_count';

+---------------------+-------+

| Variable_name | Value |

+---------------------+-------+

| Prepared_stmt_count | 1 |

+---------------------+-------+

1 row in set

不過mysql的sql語句緩存與oracle有很大不同，它是會(huì)話語句級(jí)的，不是全局共享，當(dāng)會(huì)話斷開或PreparedStatement.close后這個(gè)緩存就沒有了。我們需要設(shè)置Connection的參數(shù)cachePrepStmts=true把PreparedStatement緩存起來，prepStmtCacheSize=xxx來設(shè)置每個(gè)會(huì)話緩存語句的最大數(shù)量(很多連接池也有類似的功能)。

OK，已經(jīng)知道如何啟用預(yù)解析了，想看看啟用與不啟用預(yù)解析性能有多少差別，會(huì)不會(huì)也像oracle那么明顯呢？經(jīng)過簡單的測(cè)試，發(fā)現(xiàn)當(dāng)沒有PreparedStatement緩存(cachePrepStmts=false)時(shí)，打開預(yù)解析性能下降很多， 當(dāng)有PreparedStatement緩存(cachePrepStmts=true)時(shí)，兩者性能基本一樣。這個(gè)結(jié)果讓人很失望，個(gè)人分析有幾個(gè)原因：

啟用預(yù)解析但沒有PreparedStatement緩存時(shí)，每次創(chuàng)建PreparedStatement都需要解析一次，execute時(shí)又需要交互一次，而預(yù)解析的SQL在PreparedStatement.close又不能重用，所以性能反而更差。

當(dāng)有PreparedStatement緩存時(shí)，預(yù)解析的SQL文本緩存在服務(wù)器端，但是并不會(huì)像oracle一樣緩存執(zhí)行計(jì)劃，所以每次execute時(shí)都需要解析SQL和生成執(zhí)行計(jì)劃，因此只是減少了每次execute傳輸SQL的文本大小，性能差別不大。

注：如果SQL語法錯(cuò)誤，那么服務(wù)器端預(yù)解析會(huì)出錯(cuò)，但jdbc收到預(yù)解析出錯(cuò)的信息后并不提示出錯(cuò)，而是將取消本條語句預(yù)解析的狀態(tài)，execute時(shí)直接把SQL接裝發(fā)送給服務(wù)器，mysql jdbc在PreparedStatement構(gòu)造函數(shù)中代碼如下，其中返回ServerPreparedStatement類表示使用了綁定變量，返回PreparedStatement表示未使用綁定變量：

try {

pStmt = ServerPreparedStatement.getInstance(getLoadBalanceSafeProxy(), nativeSql,

this.database, resultSetType, resultSetConcurrency);

pStmt.setResultSetType(resultSetType);

pStmt.setResultSetConcurrency(resultSetConcurrency);

} catch (SQLException sqlEx) {

// Punt, if necessary

if (getEmulateUnsupportedPstmts()) {

pStmt = (PreparedStatement) clientPrepareStatement(nativeSql, resultSetType, resultSetConcurrency, false);

} else {

throw sqlEx;

}

} 經(jīng)過上面分析，個(gè)人認(rèn)為不需要打開SQL預(yù)解析的效果，PreparedStatement對(duì)象還是盡量使用，因?yàn)殡m然不能提升性能，但可以避免SQL注入安全問題 。

2012-02-17

分享到：

2012-02-17 00:07

瀏覽 764

評(píng)論

總結(jié)

以上是生活随笔為你收集整理的mysql jdbc 绑定变量_jdbc测试mysql数据库sql预解析(绑定变量)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。