PreparedStatement真的比Statement快吗？

我觉得很莫名，MySQL是否支持PrepareStatement和你是否使用PrepareStatement根本就是两回事。我绝对不会因为MySQL某个版本不支持的特性而改变一个良好的编程习惯，更何况，楼上的这种测试事实上没有任何实际意义。正如Robbin所说，你如何模拟生产环境呢？

不辩不明事理
良好的编程习惯是什么？习惯又由何而来？
何况楼主、lucas和很多人，都是基于测试数据在进行怀疑，没有任何不好的地方

不是同一个问题。
我们做的这个事情，并不能证明日常编程中应该使用Statement而不是PreparedStatement，相反，我觉得仍然是PreparedStatement更合适。有很多理由，1.防止SQL injection，2.自动类型转换，而获得更好的可移植性；3.更好的性能（尤其是对Oracle，MySQL不一定）

但我们的意义在于，深入理解一些常识背后的知识，而且我们发现有些常识不是那么准确的。
这个问题就象很多Java技术书籍里讲String的知识一样，很多细节不是看上去那样的，不是那么统一的。

现在的问题并不是不能模拟生产环境，而是Robbin提出的方案过于难以实现，或者代价太大。
什么叫“做一个真实的web应用”？具体有什么特性？
还要用Statement实现一遍，再用PreparedStatement改写一遍？

我难以做到这样的测试，但另一方面，你们也难以执行你们的方案以证明你们的观点。所以这样的方案对于我们来说，由于操作性低，这才是无意义的。

我们可以做较复杂的SQL测试，也可以多线程的压力测试。唯独难以做到“真实的应用”，假使做到了一个真实的，你又可以说你那种是特例，又需要在什么什么情况下再测试。其实你们所谓的真实应用，最多也不过是某一类应用，不能代表所有的情况，不是么？

昨天和公司的oracle dba讨论过oracle sql执行的具体细节：oracle 执行sql时，首先要分析sql生成查询计划，具体有：分析sql的合法性（到数据库schema中查询），决定使用某个的哪段索引（好像是这样说的）... ...，然后在第一次查询时，用物理读，其后相同的查询计划都是逻辑读，是到缓存里面读。
所以我想PreparedStatement是不是有利于oracle生成查询计划，或许还有别的帮助，所以提高了性能。
但有一点是肯定的，PreparedStatement一定需要driver具体实现才行，Prepared是缓存在数据库端的，要看看oracle jdbc驱动的实现代码才有发言权吧。
另外：我们讨论这些，纯粹是要理解jdbc具体的细节，和操作数据库的底层实现，这些应该是基础知识吧。知其然，并知其所以然。

connection关闭后，PreparedStatement就失去了作用，如果是一个connection那ps的效果就出来了

据说mysql的ps最终也是拼装字符串，所以效率反而差点

所以我们要用connection pool

执行次数较多的sql，还是用pstmt快

有书提到过，不过是针对oracle
http://www.onjava.com/pub/a/onjava/excerpt/oraclejdbc_19/index.html?page=2

按照JDBC规范的想法，实际上preparedstatement的出现主要的目的是为了提高SQL语句的的性能，而防止SQL注入和类型转换实际上并不是规范原本的目标。但是实践中这两个功能却受到更多的欢迎。

preparedstatment性能是否能提高性能，实际要具体的看数据库服务器端处理复杂SQL的情况，对于oracle而言在复杂的SQL上面二者性能差异明显（可以使用报表系统的SQL来测试），而比较简单的数据库MySQL和PostgreSQL其的性能提升不明显。在这些某些版本的JDBC实现Preparedstatement的实现就是直接使用statment的实现。

Statement 在select语句的时候比PreparedStatement效率高.
其他的都是PreparedStatement高.

PreparedStatement可以避免拼sql的时候那些讨厌的引号和字符串连接符，而且将sql文本的书写与参数的绑定分开，代码清晰很多。以前用delphi的时候，一直就是用参数法查询的。