從時(shí)序圖中可以看到,createNewIO()就是新建了一個(gè)com.mysql.jdbc.MysqlIO,利用 com.mysql.jdbc.StandardSocketFactory來創(chuàng)建一個(gè)socket。然后就由這個(gè)mySqlIO來與MySql服務(wù)器進(jìn)行握手(doHandshake()),這個(gè)doHandshake主要用來初始化與Mysql server的連接,負(fù)責(zé)登陸服務(wù)器和處理連接錯(cuò)誤。在其中會(huì)分析所連接的mysql server的版本,根據(jù)不同的版本以及是否使用SSL加密數(shù)據(jù)都有不同的處理方式,并把要傳輸給數(shù)據(jù)庫(kù)server的數(shù)據(jù)都放在一個(gè)叫做packet的 buffer中,調(diào)用send()方法往outputStream中寫入要發(fā)送的數(shù)據(jù)。
useServerPreparedStmts置為true的話,mysql驅(qū)動(dòng)可以通過PreparedStatement的子類ServerPreparedStatement來實(shí)現(xiàn)真正的PreparedStatement的功能
第一位表示數(shù)據(jù)包的開始位置,就是數(shù)據(jù)存放的起始位置,一般都設(shè)置為0,就是從第一個(gè)位置開始。第二和第三個(gè)字節(jié)標(biāo)識(shí)了這個(gè)數(shù)據(jù)包的大小,注意的是,這個(gè)大小是出去標(biāo)識(shí)的4個(gè)字節(jié)的大小,對(duì)于非最后一個(gè)數(shù)據(jù)包來說,這個(gè)大小都是一樣的,就是splitSize,也就是maxThreeBytes,它的值是 255 * 255 * 255。
最后一個(gè)字節(jié)中存放的就是數(shù)據(jù)包的編號(hào)了,從0開始遞增。
在標(biāo)識(shí)位設(shè)置完畢之后,就可以把255 * 255 * 255大小的數(shù)據(jù)從我們準(zhǔn)備好的待發(fā)送數(shù)據(jù)包中copy出來了,注意,前4位已經(jīng)是標(biāo)識(shí)位了,所以應(yīng)該從第五個(gè)位置開始copy數(shù)據(jù)
# packetToSend = compressPacket(headerPacket, HEADER_LENGTH,
# splitSize, HEADER_LENGTH);
LoadBalancingConnectionProxy
package java.lang.reflect 。 proxy .
http://developer.51cto.com/art/200907/137823.htm
http://dev.mysql.com/doc/refman/5.1/en/connector-j-reference-implementation-notes.html
PreparedStatements are implemented by the driver, as MySQL
does not have a prepared statement feature. Because of this,
the driver does not implement
getParameterMetaData()
or
getMetaData()
as it would require the
driver to have a complete SQL parser in the client.
Starting with version 3.1.0 MySQL Connector/J, server-side
prepared statements and binary-encoded result sets are used
when the server supports them.
但這是不是說PreparedStatement沒用呢?不是的,PreparedStatement有其他的好處:
1.代碼的可讀性和可維護(hù)性
2.最重要的一點(diǎn)是極大地提高了安全性,可以防止SQL注入
然后我又看了一些網(wǎng)上其他人的經(jīng)驗(yàn),基本和我的判斷一致,有兩點(diǎn)要特別提請(qǐng)大家注意:
1.并不是說PreparedStatement在所有的DB上都不會(huì)提高效率,PreparedStatement需要服務(wù)器端的支持,比如在
Oracle上就會(huì)有顯著效果。上面說的測(cè)試都是在MySQL上測(cè)試的,我找到了一個(gè)MySQL架構(gòu)師的帖子,比較明確地說明了MySQL不支持
PreparedStatement。
2.即便PreparedStatement不能提高性能,在少數(shù)使用時(shí)甚至?xí)档托?,但仍然?yīng)該使用PreparedStatement!因?yàn)槠渌?
處實(shí)在是太大了!當(dāng)然,當(dāng)SQL查詢比較復(fù)雜時(shí),可能PreparedStatement好處會(huì)更大,只是我沒有測(cè)試,不敢肯定。
3.既然PreparedStatement不能提高效率,那PreparedStatement Pool也就沒有必要了。但可以看到每次新建Connection的開銷實(shí)在很大,因此Connection Pool絕對(duì)必要。