SQL 語句文本對于數據庫來說，是一種指令，與 Shell 中輸入的一條條命令行很類似。我們在 SQL 中混入的各種值就是操作的參數。

考慮一個 WHERE user_id = 10 的篩選，WHERE 的條件包含兩個部分：按用戶篩選，以及用戶 id 的值，后者即為篩選操作的參數。

當用戶 id 直接混在 SQL 中，表示 id 值的文本作為 SQL 正文的一部分，就很容易被動手腳，攻擊者只要偽造一個令你最終也能符合語法的 偽裝值就行。

比如 WHERE user_id = 10;delete from xxxx

這樣，工程師直接拼到里面之后，在執行引擎里，它分析我們的語句，發現是兩個子句。就會執行后面的注入的 SQL。

上述過程的問題在于，執行引擎理解到的 SQL 語義與我們要表達的不一致。我們隱含地意思是，在 WHERE user_id = 之后的值都被當作 user_id 的篩選條件，而不應該有其他語句出現。但是，基于 SQL 分析來執行數據交互，這種誤解是無法解除的，比如，上面的例子，偽裝之后，它也是個符合語法的 SQL。

參數化為我們提供了消除這種誤解的能力。在遇到參數時，不管輸入任何值，都將整個值作為參數的值，而不是原始 SQL 文本的一部分。

在上面的例子里，如果使用參數化 SQL，則 10;delete from xxxx 整體會作為用于比對的 user_id 值，顯然找不到。而且數據庫不會被注入，因為這時 delete from xxxx 是參與運算的值的一部分，而不是 SQL 操作指令的一部分。

其他答案里有提到，這是一種抽象。如果做過表達式解析的練習，你會發現，操作數與操作算子是兩種不同性質的東西。

SQL 注入的原理就是，如果簡單地通過拼接字符串來獲得 SQL 文本，就會使本應屬于操作數的內容被當作操作算子來執行了。

總結

以上是生活随笔為你收集整理的mysql参数化查询为什么可以实现_为什么参数化SQL查询可以防止SQL注入?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。