关于使用占位符来解决SQL注入

总结：

SQL已经预编译好了，然后替换中间的占位符，这个占位符在编译后就已经确定了它只是一个参数属性。因此，用注入的代码去替换占位符，这个SQL也不会再进行编译了，所以也达不到注入的目的。

SQL注入并不是一个在SQL内不可解决的问题，这种攻击方式的存在也不能完全归咎于SQL这种语言，因为注入的问题而放弃SQL这种方式也是因噎废食。首先先说一个我在其他回答中也曾提到过的观点：没有（运行时）编译，就没有注入。

SQL注入产生的原因，和栈溢出、XSS等很多其他的攻击方法类似，就是 未经检查或者未经充分检查 的 用户输入数据 ， 意外变成了代码被执行 。针对于SQL注入，则是用户提交的数据，被数据库系统编译而产生了开发者预期之外的动作。也就是，SQL注入是用户输入的 数据 ，在拼接SQL语句的过程中，超越了数据本身，成为了SQL语句查询逻辑的一部分，然后这样被拼接出来的SQL语句被数据库执行，产生了开发者预期之外的动作。

所以从根本上防止上述类型攻击的手段，还是避免数据变成代码被执行，时刻分清代码和数据的界限。而具体到SQL注入来说，被执行的恶意代码是通过数据库的SQL解释引擎编译得到的，所以只要避免用户输入的数据被数据库系统编译就可以了。

现在的数据库系统都提供SQL语句的预编译（prepare）和查询参数绑定功能，在SQL语句中放置占位符'?'，然后将带有占位符的SQL语句传给数据库编译，执行的时候才将用户输入的数据作为执行的参数传给用户。这样的操作不仅使得SQL语句在书写的时候不再需要拼接，看起来也更直接，而且用户输入的数据也没有机会被送到数据库的SQL解释器被编译执行，也不会越权变成代码。

至于为什么这种参数化的查询方式没有作为默认的使用方式，我想除了兼容老系统以外，直接使用SQL确实方便并且也有确定的使用场合。

多说一点，从代码的角度来看，拼接SQL语句的做法也是不恰当的。

DELETE FROM planet WHERE name = 'mercury';
DELETE FROM planet WHERE name = 'venus';
DELETE FROM planet WHERE name = 'earth';
DELETE FROM planet WHERE name = 'mars';

我修改一下那个很经典的笑话：程序员不应该执行 删除地球 这样的SQL语句，而是写 删除一个行星 ，然后将地球当作参数传入。

$stmt = $mysqli->prepare("DELETE FROM planet WHERE name = ?");
$stmt->bind_param('s', "earth");
$stmt->execute();

更多阅读：
MySQL :: MySQL 5.1 Reference Manual :: 13.5 SQL Syntax for Prepared Statements
Prepared statement