MySQL与JDBC之间的SQL预编译技术讲解

先说一下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

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

最新评论