先说一下SQL预编译的好处吧
- 减少每次执行语句时解析语句的开销。 通常，数据库应用程序处理大量几乎相同的语句，只对语句中的文字值或变量值进行更改
- 防止SQL注入攻击。 参数值可以包含未转义的SQL引号和分隔符。
不过在这之前我一直以为JDBC预编译技术是依赖数据库MySQL实现，现在才知道SQL预编译也是分服务端和客户端实现的。
JDBC默认是客户端处理SQL预编译的，如果向指定用服务端SQL预编译的话，可以在数据源连接上配置useServerPrepStmts=true，这样就可以开启服务端SQL预编译。
当然这也是要服务端支持SQL预编译，拿MySQL5.7以上来讲是支持的。
下面贴上MySQL官方文档截图
如何验证SQL预编译是用得服务端实现还是客户端实现呢，这里参考了一篇文章点击文字即可查看。
我这里我大概说一下，以MySQL为例就是开始general_log日志，general_log日志会记录哭客户端发给服务器的SQL，这里我没就能有关参考对比了。
注意：general_log开启会产生大量日志，没有特殊情况不要在生产环境开启。
同样阅读MySQL官方文档sql-prepared-statements部分，发现MySQL实现服务端预编译是专门提供了几个语法支持的如下：
两种实现进行基准测试
这里在提供预编译技术服务端实现 && 客户端实现的基准测试供大家参考：
机器配置：
- 系统：Windows10
- CPU：AMD Ryzen 5 4600U with Radeon Graphics 2.10 GHz
- 内存：24.0 GB
- 磁盘：500GB SSD
- MySQL 用的是默认配置
结果很意外以为服务端实现应该性能要好一些，实测居然是客户端实现要好一些，不过相差微乎其微，具体如下图：
客户端实现是否存在SQL注入风险呢？
我们用代码验证一下
执行方法后查看mysql日志
我们可以看到客户端预编译也是可以保障SQL注入风险的
我们顺带看看服务端预编译是怎么样的呢?
也是没有问题。
总结
- SQL预编译区分客户端/服务端实现
- 以及对两种实现进行了基准测试，客户端SQL预编译以微弱的性能胜出，当然这个结果只能当个参考不能以偏概全
- 测试了客户端实现的SQL注入问题，测试结果通过
文末提供几个MySQL官方文档对SQL预编译说明链接有兴趣的小伙伴可以点击阅读
- Prepared Statements
- JDBC-configuration-properties
- connector-j-connp-props-prepared-statements
以上为个人经验，希望能给大家一个参考，也希望大家多多支持我们。
