SQL预编译

很多ORM框架其实底层都离不开原生的JDBC，笔记JDBC才是Java API层与数据库之间通信的标准。而在JDBC API中，SQL预编译算是非常重要的一个点，我们之所以在开发的过程中感受不到，那只是因为ORM框架和JDBC已经做的足够好了～

一、SQL预编译有两大好处：

1.1 减少语句重复编译

一条SQL语句正常编译流程是：语法分析、语义分析、语句优化、执行计划，而这些步骤是非常耗时的，而对于相同SQL语句只是参数值不同的SQL语句重复编译其实是资源浪费。

1.2 解决SQL注入

1.2.1 SQL注入原理

首先要了解为什么会有SQL注入，并且如何完成SQL注入的，比如如下代码：

public Object login(String name, String password) {
 String sql = "select count(*) from users where name = " + name + "and password = " + password;
 return dao.querySQL(sql) >= 1;
}

在上述代码中，如果传入如下参数：('chaoyang', 'pwd or 1=1')，那么这段登陆逻辑就可以被判无效了！这还不算严重，如果在你的delete逻辑中进行SQL注入，很可能要面临数据表数据丢失的危险情况。

1.2.2 预编译如何解决

在SQL预编译过程中所有的参数替换为?占位符，语句被做成类似模板的形式去进行预编译，之后的每次执行只需要将参数放入到模板中的?即可。而不需要再进行编译，因此参数中如果出现or、and这些关键字也不会再被SQL服务将其看成是保留关键字进行词法、语法的解析。

如上述SQL案例会被做成select count(*) from users where name = ? and password = ?去进行编译。

同样，当传入参数('chaoyang', 'pwd or 1=1')时，真正被执行的SQL为：
select count(*) from users where name = 'chaoyang' and password = 'pwd or 1=1 '，可以看到'pwd or 1=1'整个会变成参数值，SQL根本不会去解析or关键字。

二、JDBC规范中关乎预编译的两个参数

注意不同JDBC驱动版本对预编译的默认值不同，具体需要查看官网对着驱动包的版本去进行查看。

2.1 useServerPrepStmts

是否开启服务端预编译

2.2 cachePrepStmts

是否将预编译的结果缓存起来，下次只要是相同的SQL语句就可以直接查询缓存

三、预编译流程

首先预编译的产出对应到Java原生JDBC编程，本质就是创建PreparedStatment的过程。
下面通过一张图表述一下第二章中两个参数对于预编译过程的干预：

0.SQL预编译流程.png

四、源码查看

1.预编译源码-1.png 2.预编译源码-2.png 3.预编译源码-3.png

上述的源码中主要的两个方法分别是：

com.mysql.cj.jdbc.ConnectionImpl#prepareStatement(java.lang.String, int, int)

com.mysql.cj.jdbc.ConnectionImpl#clientPrepareStatement(java.lang.String, int, int, boolean)

五、总结

在MYSQL驱动3.x版本之后，JDBC URL中的两个相关参数就已经全部默认为False。

根据第三章的流程图来看，如果未开启服务端预编译，则PreparedStatement客户端也会进行SQL预编译，编译好的结果返回到程序员手中，之后只要setObject数据，然后execute()即可，那么看起来useServerPrepStmts没必要进行修改默认值。

那再来看第二个参数cachePrepStmts，表示是否开启预编译结果的缓存，若开启了该参数，那么PreparedStatement中会将SQL语句与预编译结果作为KV值设入全局的Map结构中。即使程序员创建了不同的PreparedStatement对象，但只要SQL语句相同，都会从缓存获取编译结果。
所以，因此个人建议将cachePreStmts设置为Ture，不论预编译是客户端做还是服务端做，开启缓存总是有益的。

六、查看日志

如何验证是否走了预编译呢，可以通过如下方式查看sql日志：
https://www.cnblogs.com/roostinghawk/p/9625886.html