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 文本，就会使本应属于操作数的内容被当作操作算子来执行了。
