原理是采用了预编译的方法，先将SQL语句中可被客户端控制的参数集进行编译，生成对应的临时变量集，再使用对应的设置方法，为临时变量集里面的元素进行赋值，赋值函数setString()，会对传入的参数进行强制类型检查和安全检查。
一、为什么参数化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树。
