很久以前,在我还在某国企的时候,我被领导要求优化一段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;
就能得到结果。