一、為什么參數化SQL查詢可以防止SQL注入

原理是采用了預編譯的方法，先將SQL語句中可被客戶端控制的參數集進行編譯，生成對應的臨時變量集，再使用對應的設置方法，為臨時變量集里面的元素進行賦值，賦值函數setString()，會對傳入的參數進行強制類型檢查和安全檢查，所以就避免了SQL注入的產生。

最近在深入學習Java，附上一段實現代碼，其他語言把賦值函數的處理封裝起來了，導致用戶不可見，不能了解其中的機理。

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();

參數查詢是數據庫原生提供的能力，而不是ado.net等數據訪問類庫提供的，后者只是對前者的封裝。我們在程序語言中寫的sql語句和參數對象，送到數據庫時還是語句和參數，并不是有些答案認為的那樣把參數的值轉好義后拼接進語句，最后把語句提給數據庫。要說類庫做了什么“預處理”，大概只是在開發者沒有顯式指定參數的類型和長度時，類庫會根據參數的值自動為其確定合適的類型和長度，僅此而已。這一點用數據庫語句跟蹤工具（如SQL Server Profiler）很容易證實。所以參數化查詢真不關程序語言/類庫多少事。

至于數據庫接到語句和參數后如何處理，我的理解/猜測是，數據庫負責解析查詢語句的子系統將語句轉換/編譯為某種底層的、數據庫執行子系統能executing的語言（好比C#編譯器把C#編譯為IL給CLR跑類似），就這一步，就將本批查詢語句的語義固化成了一套行為動作，這套行為動作正是所謂的“執行計劃”，執行計劃描述的東西大概是從什么地方取數據、如何處理數據等等，這也是為什么表名、字段名不能參數化的原因，因為這些東西都不確定的話根本沒法生成執行計劃。至于參數的值有沒有影響執行計劃的生成，是有的，但它影響的是這個值能否命中某個索引、統計信息等性能相關的東西，能的話就生成更優的執行計劃（精確指引到某個頁取數據之類），否則走笨方法（如全表掃描），而不會對整套計劃的綱領造成影響，這個就是參數化能防注入的原因所在。

簡單總結，參數化能防注入的原因在于，語句是語句，參數是參數，參數的值并不是語句的一部分，數據庫只按語句的語義跑，至于跑的時候是帶一個普通背包還是一個怪物，不會影響行進路線，無非跑的快點與慢點的區別。

延伸閱讀：

二、主要的單機存儲引擎

1、哈希存儲：hash的CRUD是非常快的。但缺點是不支持順序掃描。bitcask是一個基于hash表結構的存儲系統。他將寫操作（包括刪除標識）追加到文件尾。并定期合并新老文件&記錄。

2、B樹：既支持隨機讀取又支持范圍查找的系統。查找時間復雜度為logd(n)（d為每個節點的出度）。Mysql的InnoDB的引擎和OS的文件系統使用的就是B+樹。（為什么選擇使用B樹的變種B+樹，讀者有興趣可以去探究下。提示：磁盤讀取）

3、LSM樹(Log Structured Merge Tree)：由B+數改進而來。其思想為：將增量寫操作保存在內存中，超過閾值時刷入磁盤，從而減少隨機寫磁盤操作。讀操作則需要合并磁盤數據和內存中的寫操作。通過Memtable/SSTable實現，實現細節在此不做深入探究。比較適合寫操作較多的業務場景。BigTable/HBase/Cassandra中的列簇的數據存儲方式采用的即是LSM樹。