很久以前，在我还在X唐电信的时候，我被领导要求优化一段SQL。说真的那个时候我根本不知道SQL的优化为何物，但是百度google之后我发现所有的资料都写有这么一条：把选择性大的条件子句写在最后。因为oracle在执行的时候从底向顶执行。这句话我当时笃信不疑。可是后来我查到更多资料以及对SQL优化有了更深的理解之后，我发现那句话是RBO，而现在的oracle采取CBO。那么SQL到底是不是从下向上执行的？这个疑问后来在一次错误中被解决了。
有这么一个表，叫做test，有两个字段ser_id，area_id。但是我记不住了，我写了以下的SQL：
select * from test
where area_id = 290
and name = 'Lee'
and class_id = '201201';
执行一把：
系统会报错，但是系统不会说“name”也是无效的，只是检测出了class_id无效。这也就是说明，在进行语句的解析时，oracle确确实实是从下向上执行的。那么是不是说把选择性大的条件写到最底下会最快呢？我想这个还是靠执行计划说话。
还是这个test表，现在有12582912条数据，其中area_id=290的数据有4291456条，而ser_id=100001的有2097152条。很明显，area_id=290更具有选择性。好，现在SQL语句1如下：
select * from test
where ser_id = 100001
and area_id = 290;
它的执行计划如下：
将条件反转，在看执行计划：
惊奇的发现两个的执行计划是一样的。但是有点不同，就是物理读。可以看到第一个进行了27次物理读，而第二个SQL没有物理读。我想物理读的产生原因大家都是知道的，这里物理读少了是因为需要的数据是一样的，所以第二次直接从缓存中读出了需要的数据。但是不管物理读如何，两个执行计划是一样的，这就证明了oracle，起码是我本机装的11g，并没有因为条件子句的选择性高低而更改其执行计划。
下面是第二部分，这周学会了一个基本的SQL语句：having。
这个语句很好用，一般用来统计重复数据的时候非常非常好使。比如说我上面那个test表吧，我想知道ser_id=100001这条数据记录重复了多少遍，只需要这样写SQL：
select ser_id, count(*)
from TEST
WHERE ser_id = 100001
group by ser_id
having count(*) > 1;
就能得到结果。
作者 wingsless