SQL优化之针对count、表的连接顺序、条件顺序、in及exist的优化

本文详述了SQL优化中针对count、表的连接顺序、条件顺序、in及exist的优化，非常具有实用价值！详述如下：

一、关于count

看过一些网上关于count(*)和count(列)的文章，count(列)的效率一定比count(*)高吗？

其实个人觉得count(*)和count(列)根本就没有可比性，count(*)统计的是表里面的总条数，而count(列)统计的是当列的非空记录条数。

不过我们可以通过实验来比较一下：

首先创建测试表：

执行

发现耗时是一样的，难道他们的效率其实是一样的吗？

我们在列object_id上创建索引试试看

然后再执行

发现count(object_id)的速度明显比count(*)高出一大截，难道是因为count(object_id)能用到索引，所以效率才提高了很多？

我们再修改下object_id的列属性

然后再执行

发现其实他们的速度是一样快的，count(*)也可用到索引。
其实。

对于oracle优化器来说，我们可以通过实验发现，。

二、关于in和exist

关于in和exist的说法大都是说in的效率比exist高，所以有in的地方必需得换成exist等等。但是真的是这样的吗？

下面我们来做个试验：

在Oracle 10g中;

我们发现，exist确实比in的效率高啊。这个说法貌似是成立的啊。

但是我们再执行下面的语句

你会发现加上非空的约束条件后，in和exist的效率是一样的。

查看三个语句的执行计划你就会发现，没有加上非空约束的in语句和exist语句走的都是ANTI半连接算法，所以效率是一样的，而未加非空约束的in语句用的是filter，而不是ANTI算法，所以效率就差一些。

所以我们可以得出结论：

在Oracle 11g中：

我们发现两个语句的效率是一样的，查看执行计划也是一样的。原来oracle在11g中已经做了优化，所以in和exist的效率是一样的。

由此我们可以得出结论，。

三、关于大小表的连接顺序

在网上我们可以看到很多这样的文章，在进行多表查询的时候，用小表或者交叉表做基础表，放在后面，大表放在from后面的位置，因为表的访问顺序是从右往左的。

但是真的是这样的吗？

我们可以做实验验证一下（此处测试环境为 Oracle 11g）：

我们查看执行计划可以发现，这两个语句的效率是一样的，难道多表查询，表的顺序和效率无关吗？

我们在执行下面的语句：

我们可以清楚的发现，小表在右，大表在左的语句，查询效率高很多。

其实，在基于规则时代，查询效率是和表的连接顺序相关的，小表或者交叉表在左，大表在右的执行效率会高一些。但是现在基本上是基于代价的时代，所以大小表的顺序和效率无关，oracle优化器会自动去进行效率优化。

四、where子句中的连接条件顺序

在基于规则时代，oracle采用自下而上的顺序来解析where子句，根据这个原理，我们一般会将可能返回行数最少的表放在最后面，where子句中有过滤条件的子句放在最后面。

但是在现在基于代价时代，这种优化都有oracle优化器帮忙优化了，所以关于表的顺序和条件的顺序已经不会影响我们的查询效率了。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!