一、為什么參數(shù)化SQL查詢可以防止SQL注入
原理是采用了預(yù)編譯的方法,先將SQL語句中可被客戶端控制的參數(shù)集進(jìn)行編譯,生成對應(yīng)的臨時變量集,再使用對應(yīng)的設(shè)置方法,為臨時變量集里面的元素進(jìn)行賦值,賦值函數(shù)setString(),會對傳入的參數(shù)進(jìn)行強(qiáng)制類型檢查和安全檢查,所以就避免了SQL注入的產(chǎn)生。
最近在深入學(xué)習(xí)Java,附上一段實(shí)現(xiàn)代碼,其他語言把賦值函數(shù)的處理封裝起來了,導(dǎo)致用戶不可見,不能了解其中的機(jī)理。
import java.sql.PreparedStatement;
String sql = “select * from user where username=? and passwd=?”;
ps = conn.PreparedStatement(sql);
ps.setString(1, “admin”);
ps.setString(2, “123456”);
resultSet = ps.executeQuery();
參數(shù)查詢是數(shù)據(jù)庫原生提供的能力,而不是ado.net等數(shù)據(jù)訪問類庫提供的,后者只是對前者的封裝。我們在程序語言中寫的sql語句和參數(shù)對象,送到數(shù)據(jù)庫時還是語句和參數(shù),并不是有些答案認(rèn)為的那樣把參數(shù)的值轉(zhuǎn)好義后拼接進(jìn)語句,最后把語句提給數(shù)據(jù)庫。要說類庫做了什么“預(yù)處理”,大概只是在開發(fā)者沒有顯式指定參數(shù)的類型和長度時,類庫會根據(jù)參數(shù)的值自動為其確定合適的類型和長度,僅此而已。這一點(diǎn)用數(shù)據(jù)庫語句跟蹤工具(如SQL Server Profiler)很容易證實(shí)。所以參數(shù)化查詢真不關(guān)程序語言/類庫多少事。
至于數(shù)據(jù)庫接到語句和參數(shù)后如何處理,我的理解/猜測是,數(shù)據(jù)庫負(fù)責(zé)解析查詢語句的子系統(tǒng)將語句轉(zhuǎn)換/編譯為某種底層的、數(shù)據(jù)庫執(zhí)行子系統(tǒng)能executing的語言(好比C#編譯器把C#編譯為IL給CLR跑類似),就這一步,就將本批查詢語句的語義固化成了一套行為動作,這套行為動作正是所謂的“執(zhí)行計劃”,執(zhí)行計劃描述的東西大概是從什么地方取數(shù)據(jù)、如何處理數(shù)據(jù)等等,這也是為什么表名、字段名不能參數(shù)化的原因,因為這些東西都不確定的話根本沒法生成執(zhí)行計劃。至于參數(shù)的值有沒有影響執(zhí)行計劃的生成,是有的,但它影響的是這個值能否命中某個索引、統(tǒng)計信息等性能相關(guān)的東西,能的話就生成更優(yōu)的執(zhí)行計劃(精確指引到某個頁取數(shù)據(jù)之類),否則走笨方法(如全表掃描),而不會對整套計劃的綱領(lǐng)造成影響,這個就是參數(shù)化能防注入的原因所在。
簡單總結(jié),參數(shù)化能防注入的原因在于,語句是語句,參數(shù)是參數(shù),參數(shù)的值并不是語句的一部分,數(shù)據(jù)庫只按語句的語義跑,至于跑的時候是帶一個普通背包還是一個怪物,不會影響行進(jìn)路線,無非跑的快點(diǎn)與慢點(diǎn)的區(qū)別。
延伸閱讀:
二、主要的單機(jī)存儲引擎
1、哈希存儲:hash的CRUD是非??斓摹5秉c(diǎn)是不支持順序掃描。bitcask是一個基于hash表結(jié)構(gòu)的存儲系統(tǒng)。他將寫操作(包括刪除標(biāo)識)追加到文件尾。并定期合并新老文件&記錄。
2、B樹:既支持隨機(jī)讀取又支持范圍查找的系統(tǒng)。查找時間復(fù)雜度為logd(n)(d為每個節(jié)點(diǎn)的出度)。Mysql的InnoDB的引擎和OS的文件系統(tǒng)使用的就是B+樹。(為什么選擇使用B樹的變種B+樹,讀者有興趣可以去探究下。提示:磁盤讀?。?/p>
3、LSM樹(Log Structured Merge Tree):由B+數(shù)改進(jìn)而來。其思想為:將增量寫操作保存在內(nèi)存中,超過閾值時刷入磁盤,從而減少隨機(jī)寫磁盤操作。讀操作則需要合并磁盤數(shù)據(jù)和內(nèi)存中的寫操作。通過Memtable/SSTable實(shí)現(xiàn),實(shí)現(xiàn)細(xì)節(jié)在此不做深入探究。比較適合寫操作較多的業(yè)務(wù)場景。BigTable/HBase/Cassandra中的列簇的數(shù)據(jù)存儲方式采用的即是LSM樹。