没有 Fast=true的选项(求求你，别再说索引比全表扫描快了)

没有fast=true的设置,有人说or 比 in 好，exists 比in 好,索引比全表扫描好，分区能提高查询效率，但是分区要降低插入效率

我要说的是，没有fast=true的选项， 如果能找到一步，或者几步公式化的方法能提高效率，那么优化器自己就会做了，根本不用用户担心。

假设 or比in好，数据库优化器把in语法和or语法走的执行计划一样就可以了，何必折磨用户呢。

说点实际的，很多人张嘴就说，SQL优化就是避免全表扫描，不知道大家有没有了解过索引查找的原理.索引查找数据，有两步要做，第一步是索引中快速查询，索引里只存储了对应表数据的rowid, 所以还有第二步，根据rowid去得到全部的数据, 所以需要一次磁盘i/o, 不要小看磁盘I/O,通过索引查询出的结果比较多的时候，磁盘i/o的时间是非常大的，这个时候比全表扫描慢得多， 实际上，oracle 10g基于成本的优化器(CBO)，选择性不高的索引，优化器根本不会使用，而自动采用全表扫描的方式来做. 

某个选项设置，某个方法，都是一定前提，一定环境下才适用的。

不错。大数据量读取全表比索引要好得多。而且索引过多造成的插入、修改和删除性能下降相当厉害。
到处乱建索引的话，索引的空间甚至比表还大。造成性能和维护成本都受影响。所以性能有风险，索引要谨慎。

非常同意

如：in和exists 到底有没有区别，还是根据具体数据库，具体sql语句等情况有不同。简单查看一下执行计划是比较好的办法（这里把执行计划变化的因素暂不考虑）。

千万不要成为Voodoo数据库专家，大道不走，老总结一些过时的、或时而灵验时而不灵的歪招。

可以详细展开说一下么？单指oracle还是所有数据库都是这样？或说在某种条件下？在mysql中千万记录的全表和index是不同数量级的，或者我理解错了？望详解……

这是一个基本道理，用不着这么标题党了吧。

索引怎么建当然要看具体情况具体分析，本来就不存在放之四海而皆准的道理，比方说如果你索引的字段重复数据很多的话，当然索引还不如不建，例如用户的性别字段，不是男就是女，你给这种字段建索引，那就是纯粹找抽，这就是楼主想表达的中心思想。

这是指你一次要读取几百甚至上千条纪录的情况。注意：不是查询，而是要读出来。比如你要从10000条记录中读取1000条的结果集（所有字段）。这种情况下你用索引还不如全表快。因为数据太多了。全表找到一条，就把这条的结果取出来了。索引要先走一遍索引，然后根据结果再一条一条到表里取，速度反而慢下来了。

根据oracle的training ppt，当返回行数少于表总行数的4%的时候，使用索引才是最恰当的。