不要迷信所谓的“SQL优化原则”????? ???? 网上我们经常可以找到大量的关于sql调优的文章和帖子，实际上如果
不要迷信所谓的“SQL优化原则”
?????
???? 网上我们经常可以找到大量的关于sql调优的文章和帖子，实际上如果没有真正的实践，可以说这些所谓的经验总结，在实际中不一定总是正确和有效。因此很容易误导初学者，对于某个sql的怎么执行还是要看实际执行计划，下面就大家容易出现的误解做下说明。
?
不一定，如果join 一个是子查询，一个是物理表，物理表在关联字段建立了索引，也是可以利用索引的，如果子查询或者视图不包含group by，在子查询外的where条件在 有时相当于拿到子查询中。
?
例如：select field1 from (select filed1 from table)tmp where filed1>1000
实际上相当于select filed1 from table where field1>1000
?
我们会在网上或者课本上翻出预编译sql相对于非预编译sql的优势，例如：
预编译sql防止了SQL注入，不必考虑特殊字符的转译，提高了安全性，而且数据库会将SQL存储到共享池中，以便下次使用。
?
但是，在项目中，我们发现在plsqldeveloper中执行时间为7s的sql，在应用程序中执行却需要3分钟，随后我们改为非预编译sql，执行时间与在工具中的执行时间相同。（IBatis的配置文件的##全部改为$$,SQL将变为非预编译SQL）。改为非预编译SQL，
?
Oracle的sharepool不会存储非预编译sql的执行计划了吗？但是我们可以很清楚的看到在工具中第一次执行sql是比较慢的，第二次执行就会快些。
SQL的执行计划是经过DBMS的查询分析器经过比较选取的，根据数据量的不同，数据的不同，会产生不同的执行计划，如果数据量比较小，或者使用索引的Cost还不如全表扫描，那么查询分析器会采用全表扫描。
在oracle10g可以使用跳跃索引扫描，如果不使用复合索引的leading column即首列，也是可以使用该复合索引的
索引是消耗存储空间的，索引太多会导致更新或者插入很慢，因为更新或者插入会同时更新插入索引。
在DB2中有多索引扫描，详细请参考牛新庄的《DB2 DBA参考》，其中可以同时使用2个索引，然后对结果集进行合并，在oracle中还没有看到，因此有待考证。在oracle中，一般情况下，对于一个表只会使用一个索引，所以索引不必建立很多优化查询，因为一次查询只能使用一个索引，请大家讨论。
有些帖子讲应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
实际上对于简单的查询使用or和in也是可以使用索引的
还有那个in 据说
（又是据说啊）in里面是个子查询的时候不会使用索引，而具体的值的时候也会应用索引
还有那个in 据说
（又是据说啊）in里面是个子查询的时候不会使用索引，而具体的值的时候也会应用索引
呃，in那个不见得，oracle的优化器还是满努力的，有时候会优化成相当于把子查询打开、先连接、再筛重复的形式。 11 楼 liwenjie 2010-05-04 miaow 写道怎么觉得很多是老生常谈呢，是有些抄来抄去的网文太老吧
2 我相信有什么地方搞错了，虽然我不认为预编译有什么性能优势，但这个差距显然是有其他地方错了。
另外，常识看是针对谁了，其实对于很多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优化的工作了。 12 楼 miaow 2010-05-04 有趣。
我承认我没做过性能测试。不过我记得oracle在TopLink的文档中强调过设置statement cache对性能有提高。
毕竟DB和TopLink都是oracle的东西，我相信oracle不会开玩笑吧。
也许和怎么用有关，看看能不能找到进一步文档。 13 楼 miaow 2010-05-05 没找到很合适的文档，这个可以参考：
http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/stmtcach.htm
按照该文的说法，要prepared statement发挥作用，恐怕要这样：
压力测试一段时间，保证pool中的connection都cache了相应statement，然后再跑一个压力测试，才能看出有相应效果。
如果是这样，看起来不是问题。
因为有一定负载下效率能提高点，我们在意的也是这情况，看来是值得的。
抱歉当前在折腾DB2，没oracle环境，又不好意思借别人的来压力测试。只好空对空了。 14 楼 jiangduxi 2010-05-05 一看标题，基本上楼主对"sql优化"迷信过，借用一句话，任何事情相信到差不多就可以了，否则就是迷信了。 15 楼 qingfengjushi1 2010-05-05 SQL优化时也要考虑Oracle的几种连接模式, NL连接, Hash连接及归并连接的内部处理机制,尽量作到缩小驱动表记录条数,不应该出现几张大表关联的情况。另外cost的值是Oracle判断选择全表扫描或使用索引的依据吧，似乎对优化的作用不大。 16 楼 novembersky 2010-05-07 关于第4点，跳跃式索引扫描9i就已经有了，虽说在没有使用复合索引的首部分（leading portion）时，可以使用子索引扫描，但是如果复合索引的首部分的选择性很高（重复值很少），那性能也会很糟糕，因为这种跳跃式索引扫描本质上是众多子查询的union。总的来说，最好还是使用复合索引的首部分最为where条件为最佳。 17 楼 whaosoft 2010-05-09 robertpi 写道因为这些文档过时了，oracle也在不断进步，不少优化都不需要了。Oracle高手都是通过metalink找资料的。
这样才好吗 程序员会省好多事 更关心与业务逻辑 18 楼 zhxp791008 2010-05-10 有兴趣的看下，基于成本的sql优化法则、oracle高性能sql、oracle性能优化内幕等，看了以后写sql就不会迷茫了。 19 楼 blackchoc 2010-05-13 不错的主题。如果我们的sql需要被优化，我们肯定会试各种方案。
实践才是正道。
呵呵 20 楼 softctwo 2010-05-13 我就是来顶你一下哈 21 楼 boylook 2011-02-10 冲着标题来的。。。看到内容闪了 22 楼 sdh5724 2011-02-14 突然想到一些事情： 总是有人试图证明爱因斯坦是错误的。 23 楼 zzhonghe 2011-02-15 也谈谈预编译和非预编译的优劣：
对于执行时间有好几秒的的SQL，从性能的观点出发的话，最好使用非预编译，这样的话，优化器能够根据你传的实际值来制定更加优良的计划。
举个例子：
有个id auto increament的表，有10万条数据。
非预编译：
select * from table where id<10 优化器会让查询走索引， 全表扫是很慢的
select * from table where id<99990 优化器知道全表扫描更好， 此时走索引要慢很多倍
而预编译
select * from table where id<？
不管是查10，还是99990，都只有一种执行计划，性能怎么样就只能靠人品了。 24 楼 wolfbrood 2011-02-16 <div class="quote_title">zzhonghe 写道</div>
<div class="quote_div">也谈谈预编译和非预编译的优劣：<br><br>对于执行时间有好几秒的的SQL，从性能的观点出发的话，最好使用非预编译，这样的话，优化器能够根据你传的实际值来制定更加优良的计划。? <br><br>举个例子：<br><br>有个id auto increament的表，有10万条数据。<br><br>非预编译：<br>select * from table where id<10? 优化器会让查询走索引， 全表扫是很慢的<br><br>select * from table where id<99990?? 优化器知道全表扫描更好， 此时走索引要慢很多倍<br><br>而预编译<br>select * from table where id<？<br><br>不管是查10，还是99990，都只有一种执行计划，性能怎么样就只能靠人品了。</div>
<p>?</p>
<p>以前我也遇到过的这种情况，在oracle 10g， 它有自己的之下你给计划，现则一跳它认为最好，结果每次都给我选择最慢的。</p>
<p>?</p>
（又是据说啊）in里面是个子查询的时候不会使用索引，而具体的值的时候也会应用索引 