1.PreparedStatement和statement对比
如果只执行单个SQL语句,那么不用说肯定是Statement的效率高,因为PreparedStatement需要花时间先预编译,但不会产生数量级的差别。
PreparedStatement带来的好处如下:
1.增加代码的可读性
全部使用statement,字符串拼SQL就象一本天书。
2.缓冲优势
WEB环境下是多个并发执行,对于关键业务,PreparedStatement比Statement优势大
Oracle数据库有一个数据缓存区,将最近用过的SQL和数据保存在内存上,只要你的SQL的数据在内存上,PreparedStatement和Statement的差别不会是数据级的(磁盘的速度太慢了)。
3.加强了安全性
传递给PreparedStatement对象的参数可以被强制进行类型转换,使开发人员可以确保在插入或查询数据时与底层的数据库格式匹配。
当处理公共Web站点上的用户传来的数据的时候,安全性的问题就变得极为重要。传递给PreparedStatement的字符串参数会自动被驱动器忽略。最简单的情况下,这就意味着当你的程序试着将字符串“D'Angelo”插入到VARCHAR2中时,该语句将不会识别第一个“,”,从而导致悲惨的失败。几乎很少有必要创建你自己的字符串忽略代码。
2.公众评价
网上大多数人是通过循环测试的,这种测试是不科学的,不能相信。下面给出部分人员评论:
2.1
写一个真实的web应用,尽量多执行一些条件查询,但是全部使用statement,字符串拼SQL。然后用loadrunner录制用户使用脚本,模拟几十个用户并发访问web应用,进行压力测试。在测试过程中,注意记录数据库服务器的CPU使用率和数据库自身的性能参数(例如Oracle的 SGA各项参数)
然后修改程序,全部改成PrepareStatment,用loadrunner再次执行同样的压力测试,在测试过程中,记录数据库服务器的CPU使用率和数据库自身的性能参数。
然后再对比两种不同查询方法的压力测试,究竟哪种对数据库负载比较重,对数据库资源消耗比较大,究竟哪种方法web应用的吞吐量更好。
这才是科学的测试。有没有人有兴趣按照我的方案测一把?
不过我可以预先告诉大家答案,那就是用preparestatment的时候,web应用的吞吐量更大,数据库负载更低,不信的呢就自己去试。
2.2
测试的目的在于指导实践。就单个请求来说statement要快,但是如果按照这种思路去写代码,后果是很严重的。因为会对数据库服务器造成很重的压力,系统吞吐量也要降低。早在2001年的时候,我维护的一个系统(访问量巨大,每天上百万),Oracle数据库每周都要宕机一次,经过几个月的排查,最终找到的原因就是我们程序所有的条件查询全部都是statement拼SQL字符串。全部改掉以后恢复正常,性能也明显提高。
实际的应用程序都是多用户并发的web应用,不是单机自己一个人用的,你们那种测试根本就不能反应实际的多用户并发的系统吞吐量和数据库负载情况,不是误导是什么?
2.3
其实PreparedStatement与statement性能差异是与数据库相关的就应用来说,个人认为性能的差距微乎其微,一条糟糕的sql产生的损耗远大于使用PreparedStatement或者statement带来的收益。
除了性能之外,Statement可能会给你的oracle带来重编译过多的烦恼,严重点导致oracle崩溃,我们的项目中曾经出现过这样的情况。
阅读(4223) | 评论(0) | 转发(1) |