用in比exists还快？

biti_rainy

最初由 yseraphi 发布
[B]如果你有索引的话，用Exists肯定比用in 快。你在执行计划种已经看到，两种方法都进行了全表扫描。但所用的优化方法是不一样的。 [/B]

如果有索引…… 就一定……

也是一个不绝对正确的结论，sql都是表象，而执行计划才是根本：
1：如果子查询里面还有其他条件，而这个条件字段又有索引，而满足这个条件的数据又很少

2：字查询的表本身数据量的大小

3：外层表这个 字段  上是否有索引

4：外层表是否有其他条件，其他条件字段是否存在索引，满足条件数据量如何

这些都是影响执行计划执行效果的因素，不同状况下最佳执行计划就可能不一样的。所以说，优化这个话题，通常，是不懂的时候背规律，逐渐的研究下去发现规律是在特定条件下成立的，逐渐的明白了 sql 到底是如何execute 的，记录是如何一条一条被识别的，这完全可以用现实的真实的模型来比拟，这样sql对于你来说不再是sql，而是一个目标，为了完成这个目标，你制定一个最优计划去实施。 这时眼中有sql心中无sql ，你就不会再关注什么总结出来的规律，是见招拆招，无招胜有招。


所以我常说，写SQL的过程：
1：了解表结构信息
2：了解需求（查询要达到的目标）
3：了解索引状况
4：了解数据特征和分布
5：了解数据库版本和优化模式、pga设置等
6：了解查询返回的大致数据量的范围（这是一个重要问题，以防止当前比较快的sql将来可能比较慢）
7：然后心中想好执行计划
8：然后写sql
9：观察sql执行计划--调整sql--以让执行计划成为自己的预期执行计划为止
10：根据情况决定是否可以稳定执行计划（可通过hints等）


我几乎还没有遇到这样下来之后的执行计划无法满足需求的，除非心中所想的就是两种以上执行计划无法甄别优劣需要通过实验来检验。

第6步是我经常要重点考察的问题，数据量少的时候NL最快，数据量大了那就HJ比较好，那我就通常选择HJ而不是当前最快的NL.



当然，要能这么做，SQL tuning 的基础知识和经验是必备的，窃以为这是书写sql的比较好的步骤，应该向这个方向努力。

zflying2000

在9i中基本上差不多。oracle也变聪明了。嘿嘿