不要迷信所谓的“SQL优化原则”

呃，in那个不见得，oracle的优化器还是满努力的，有时候会优化成相当于把子查询打开、先连接、再筛重复的形式。

另外，常识看是针对谁了，其实对于很多java程序员，不知道数据库这些常识的不少，呵呵。。

请参看下Java Programming with Oracle JDBC: Performance
http://onjava.com/lpt/a/onjava/excerpt/oraclejdbc_19/index.html
有的时候你的“相信”可能不是很准，还是以实验为准

另外，我使用的是oracle 10g 。

sql优化在现在仍然很有用，虽然oracle自己的优化很不错，为什么？？就是因为大家初期开发的时候，没有那么注意到性能问题，或者干脆有些程序员不知道如何写出漂亮的sql，导致系统开发后期会有一段专门的时间来优化sql。

可能你使用的是hibernate，可能你不从事ETL，不存在优化长大查询sql的问题，体会不到优化sql的点滴经验教训。

在优化sql的时候，我发现有些程序员有误解，或者很多网文，干脆就是误人子弟，包括JavaEye中的有些博客文章，也是这样的，轻易地得出“什么比什么快”的所谓经验，因此贴出来分享。


总之，在硬件一定的前提下，优化sql还是从实际出发，本着减少IO的大原则，实在不行就进行再次加工，比如水平、垂直切分表，当然这已经不是sql优化的工作了。

有趣。

我承认我没做过性能测试。不过我记得oracle在TopLink的文档中强调过设置statement cache对性能有提高。
毕竟DB和TopLink都是oracle的东西，我相信oracle不会开玩笑吧。

也许和怎么用有关，看看能不能找到进一步文档。

没找到很合适的文档，这个可以参考：
http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/stmtcach.htm

按照该文的说法，要prepared statement发挥作用，恐怕要这样：
压力测试一段时间，保证pool中的connection都cache了相应statement，然后再跑一个压力测试，才能看出有相应效果。

如果是这样，看起来不是问题。
因为有一定负载下效率能提高点，我们在意的也是这情况，看来是值得的。

抱歉当前在折腾DB2，没oracle环境，又不好意思借别人的来压力测试。只好空对空了。

一看标题，基本上楼主对"sql优化"迷信过，借用一句话，任何事情相信到差不多就可以了，否则就是迷信了。

SQL优化时也要考虑Oracle的几种连接模式, NL连接, Hash连接及归并连接的内部处理机制,尽量作到缩小驱动表记录条数,不应该出现几张大表关联的情况。另外cost的值是Oracle判断选择全表扫描或使用索引的依据吧，似乎对优化的作用不大。

关于第4点，跳跃式索引扫描9i就已经有了，虽说在没有使用复合索引的首部分（leading portion）时，可以使用子索引扫描，但是如果复合索引的首部分的选择性很高（重复值很少），那性能也会很糟糕，因为这种跳跃式索引扫描本质上是众多子查询的union。总的来说，最好还是使用复合索引的首部分最为where条件为最佳。

这样才好吗 程序员会省好多事 更关心与业务逻辑

有兴趣的看下，基于成本的sql优化法则、oracle高性能sql、oracle性能优化内幕等，看了以后写sql就不会迷茫了。

不错的主题。如果我们的sql需要被优化，我们肯定会试各种方案。
实践才是正道。
呵呵