预编译为什么可以防御 SQL 注入 ？

主要观点总结

文章介绍了预编译的初衷是提高代码复用性，通过SQL语句模板化和占位符替代值的位置来预先编译SQL语法结构，减少重复建立语法树的时间。以MyBatis为例，阐述了预编译过程中SQL语句的预编译和参数替换的执行过程，并指出了预编译的局限性和注意事项。

关键观点总结

关键观点1: 预编译的初衷和提高代码复用性

预编译是为了解决重复编译的问题，通过SQL语句模板化和占位符的使用，预先编译SQL语法结构。

关键观点2: 预编译的优势

预编译可以节省重复建立语法树的时间，提高数据库查询效率，同时避免SQL注入问题。

关键观点3: 预编译的使用场景

以MyBatis为例，介绍了预编译在SQL语句中的应用，以及使用占位符替代参数值的方法。

关键观点4: 预编译的局限性

预编译不适用于动态表名和列名等场景，因为这些参数无法用占位符替代，也就无法使用预编译。

文章预览

预编译最初的目的是提高代码的复用性，因为有很多只有参数值不同的 SQL（完全相同的 SQL 会从缓存里查），比如： select * from user where id='1' select * from user where id='2' 这些 SQL 的语法树相同，但每次都要进行重复的编译，很浪费时间。 而预编译可以将 SQL 语句模板化，值的位置用占位符替代，这样数据库就会事先编译好 SQL 语法结构，等真正调用的时候，再传入值执行，省掉了重复建立语法树的时间。 select * from user where id={占位符} 通过抓包来看，SQL 语句先被预编译（Prepare Statement），参数值先用占位符替代。等执行（Execute Statement）的时候，再传入参数。 用户传入的参数不参与语法树的构建，就改不了 SQL 的语法结构，也就避免了注入。 以 MyBatis（半自动化的持久层框架）为例， #{id}  这种格式传参，会先把 SQL 传给数据库进行预编译，等调用的时 ………………………………