MySQL与JDBC之间的SQL预编译技术讲解
目录
- 先说一下SQL预编译的好处吧
- 下面贴上MySQL官方文档截图
- 两种实现进行基准测试
- 客户端实现是否存在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预编译说明链接有兴趣的小伙伴可以点击阅读
以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。
赞 (0)