java中的Statement与PreparedStatement的比较

一.代码的可读性和可维护性

 主要体现在sql语句的拼接上。特别是当一个sql语句存在一个表的多个属性值或者嵌套查询时，使用字符串的拼接将会让人非常厌恶，可阅读性与可维护性急剧下降

 如下代码：
String selectdistid = "select depb_ID from districtEPB where DistrictID= (select DistrictID from district where DistrictName=\"" + user.getSelect3() + "\" and CityID=(select CityID from city where CityName=\"" + user.getSelect2() + "\"and provinceID=(select provinceID from province where provinceName=\"" + user.getSelect1() + "\")));";

 二.性能问题

实际上，JDBC只是给出了程序的接口，性能的问题依然在某种程度上依赖于某种数据库的具体实现过程，并且还要考虑相关的应用领域背景。就理论上而言，PreparedStatement较之于Statement是存在整体上性能优势的，而对於单次的动态构造的sql的执行效率而言，PreparedStatement的耗费会比Statement大。但是考虑实际情况，两者的性能上优势差距并不具有天壤之别的。诚然， PreparedStatement会有后续缓存优化查询的好处，但是网络请求成本的增加有可能 大于这个好处 。 90% 的可能性是若App Server 与 DB Server分布部署，网络请求成本的增加大于后续优化执行带来的好处。另外，还要指出的是，不仅如此，实际上Statement的执行，不一定是没有缓存的，而恰恰相反， 现在大多数的数据库软件的查询分析模块，会透明的在第一次执行 像insert into tb_name (col1,col2) values ('11','22') 这样的sql简单语句时将其转化为 insert into tb_name (col1,col2) values (？,？)， 为后面重复执行缓存优化。 当然不同的数据库实现的策略是不同的。
 

 三.安全性

PreparedStatement可以轻松做到防止SQL注入。所谓SQL注入，就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。 即使到目前为止,仍有一些人连基本的恶义SQL语法都不知道.
         String sql = "select * from tb_name where name= '"+varname+"' and passwd='"+varpasswd+"'";
如果我们把[' or '1' = '1]作为varpasswd传入进来.用户名随意,看看会成为什么?
         select * from tb_name = '随意' and passwd = '' or '1' = '1';
 因为'1'='1'肯定成立,所以可以任何通过验证.更有甚者: 把[';drop table tb_name;]作为varpasswd传入进来,则:

     select * from tb_name = '随意' and passwd = '';drop table tb_name;

有些数据库是不会让你成功的,但也有很多数据库就可以使这些语句得到执行.  而如果你使用预编译语句.你传入的任何内容就不会和原来的语句发生任何匹配的关系.只要全使用预编译语句,你就用不着对传入的数据做任何过虑.而如果使用普通的statement,有可能要对drop,;等做费尽心机的判断和过虑.

四、总结

1，对于存储大型的对象诸如BLOB，CBLOB之类使用PreparedStatement还是比较节省资源的。
2，进行批量处理的时候，建议使用PreparedStatement


参考：
1，Top Ten Oracle JDBC Tips  http://www.onjava.com/pub/a/onjava/2001/12/19/oraclejdbc.html?page=1
2，Java Programming with Oracle JDBC  http://oreilly.com/catalog/jorajdbc/chapter/ch19.html
3，SQL注入  http://www.cnblogs.com/sunnyfriday/archive/2012/10/29/javasql.html