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

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

一、关于count

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

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

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

首先创建测试表:

drop table test purge;
create table test as select * from dba_objects;

update test set object_id =rownum ;
set timing on
set linesize 1000
set autotrace on

执行

select count(*) from test;
select count(object_id) from test;

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

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

create index idx_object_id on test(object_id);

然后再执行

select count(*) from test;
select count(object_id) from test;

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

我们再修改下object_id的列属性

alter table test modify object_id not null;

然后再执行

select count(*) from test;
select count(object_id) from test;

发现其实他们的速度是一样快的,count(*)也可用到索引。
其实效率比较的前提是两个语句的写法要等价,这两种写法根本就不等价,因此不具有可比性。

对于oracle优化器来说,我们可以通过实验发现,count不同的列,统计的时间是不一样的,大致趋势是列越靠后,访问的开销越大,列的偏移量决定访问的性能。而count(*)的开销与偏移量无关。因此,在某些场合count(*)反而是最快的。

二、关于in和exist

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

下面我们来做个试验:

在Oracle 10g中;

select * from dept where deptno NOT IN ( select deptno from emp ) ;
select * from dept where not exists ( select deptno from emp where emp.deptno=dept.deptno) ;

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

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

select * from dept where deptno NOT IN ( select deptno from emp where deptno is not null) and deptno is not null;

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

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

所以我们可以得出结论:在oracle 10g中,如果可以确保非空,则in约束可以用到ANTI的半连接算法,这时候的效率和exist是一样的。

在Oracle 11g中:

select * from dept where deptno NOT IN ( select deptno from emp ) ;
select * from dept where not exists ( select deptno from emp where emp.deptno=dept.deptno) ;

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

由此我们可以得出结论,在11g中,使用in和exist的效率是一样的,因为他们走的都是比较高效的ANTI算法。

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

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

但是真的是这样的吗?

我们可以做实验验证一下(此处测试环境为 Oracle 11g):

create table tab_big as select * from dba_objects where rownum<=30000;
create table tab_small as select * from dba_objects where rownum<=10;
set autotrace traceonly
set linesize 1000
set timing on
select count(*) from tab_big,tab_small ;
select count(*) from tab_small,tab_big ;

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

我们在执行下面的语句:

select /*+rule*/ count(*) from tab_big,tab_small ;
select /*+rule*/ count(*) from tab_small,tab_big ;

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

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

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

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

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

(0)

相关推荐

  • mysql优化连接数防止访问量过高的方法

    很多开发人员都会遇见"MySQL: ERROR 1040: Too many connections"的异常情况,造成这种情况的一种原因是访问量过高,MySQL服务器抗不住,这个时候就要考虑增加从服务器分散读压力:另一种原因就是MySQL配置文件中max_connections值过小. 首先,我们来查看mysql的最大连接数: mysql> show variables like '%max_connections%'; +-----------------+-------+ |

  • mysql优化之路----hash索引优化

    创建表 CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `msg` varchar(20) NOT NULL DEFAULT '', `crcmsg` int(15) NOT NULL DEFAULT '0', PRIMARY KEY (`id`) ) ENGINE=MyISAM AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 //插入数据 insert into t1 (msg) values('w

  • MySQL优化之表结构优化的5大建议(数据类型选择讲的很好)

    殊不知,在N年前被奉为"圣经"的数据库设计3范式早就已经不完全适用了.这里我整理了一些比较常见的数据库表结构设计方面的优化技巧,希望对大家有用. 由于MySQL数据库是基于行(Row)存储的数据库,而数据库操作 IO 的时候是以 page(block)的方式,也就是说,如果我们每条记录所占用的空间量减小,就会使每个page中可存放的数据行数增大,那么每次 IO 可访问的行数也就增多了.反过来说,处理相同行数的数据,需要访问的 page 就会减少,也就是 IO 操作次数降低,直接提升性能

  • MySQL优化之如何查找SQL效率低的原因

    查询到效率低的 SQL 语句 后,可以通过 EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息,包括在 SELECT 语句执行过程中表如何连接和连接的顺序,比如我们想计算 2006 年所有公司的销售额,需要关联 sales 表和 company 表,并且对 profit 字段做求和( sum )操作,相应 SQL 的执行计划如下: mysql> explain select sum(profit) from sales a,company b where a

  • MySQL优化之对RAND()的优化方法

    众所周知,在MySQL中,如果直接 ORDER BY RAND() 的话,效率非常差,因为会多次执行.事实上,如果等值查询也是用 RAND() 的话也如此,我们先来看看下面这几个SQL的不同执行计划和执行耗时. 首先,看下建表DDL,这是一个没有显式自增主键的InnoDB表: 复制代码 代码如下: [yejr@imysql]> show create table t_innodb_random\G *************************** 1. row **************

  • mysql优化limit查询语句的5个方法

    mysql的分页比较简单,只需要limit offset,length就可以获取数据了,但是当offset和length比较大的时候,mysql明显性能下降 1.子查询优化法 先找出第一条数据,然后大于等于这条数据的id就是要获取的数据 缺点:数据必须是连续的,可以说不能有where条件,where条件会筛选数据,导致数据失去连续性,具体方法请看下面的查询实例: 复制代码 代码如下: mysql> set profiling=1; Query OK, 0 rows affected (0.00

  • MySQL优化GROUP BY方案

    执行GROUP BY子句的最一般的方法:先扫描整个表,然后创建一个新的临时表,表中每个组的所有行应为连续的,最后使用该临时表来找到组并应用聚集函数(如果有聚集函数).在某些情况中,MySQL通过访问索引就可以得到结果,而不用创建临时表.此类查询的 EXPLAIN 输出显示 Extra列的值为 Using index for group-by. 一. 松散索引扫描 1.满足条件 查询针对一个表.  GROUP BY 使用索引的最左前缀.  只可以使用MIN()和MAX()聚集函数,并且它们均指向相

  • 21条MySQL优化建议(经验总结)

    今天一个朋友向我咨询怎么去优化 MySQL,我按着思维整理了一下,大概粗的可以分为21个方向. 还有一些细节东西(table cache, 表设计,索引设计,程序端缓存之类的)先不列了,对一个系统,初期能把下面做完也是一个不错的系统. 1. 要确保有足够的内存 数据库能够高效的运行,最关建的因素需要内存足更大了,能缓存住数据,更新也可以在内存先完成.但不同的业务对内存需要强度不一样,一推荐内存要占到数据的15-25%的比例,特别的热的数据,内存基本要达到数据库的80%大小. 2. 需要更多更快的

  • SQL字段拆分优化

    今天看到一条用函数处理连接的SQL,是群里某位网友的,SQL语句如下: SELECT SO_Order.fdate , SO_Order.fsn FROM so_order INNER JOIN so_orderitem ON CHARINDEX(so_Orderitem.fid, SO_Order.fid) >= 1 WHERE so_order.FOrderDate = '2015-09-06' 语句不算复杂,只是执行比较慢,下面是关于这SQL语句的一些信息: --1.SQL执行203条数据

  • Oracle 表三种连接方式使用介绍(sql优化)

    1. NESTED LOOP 对于被连接的数据子集较小的情况,nested loop连接是个较好的选择.nested loop就是扫描一个表,每读到一条记录,就根据索引去另一个表里面查找,没有索引一般就不会是 nested loops.一般在nested loop中, 驱动表满足条件结果集不大,被驱动表的连接字段要有索引,这样就走nstedloop.如果驱动表返回记录太多,就不适合nested loops了.如果连接字段没有索引,则适合走hash join,因为不需要索引. 可用ordered提

  • 人工智能自动sql优化工具--SQLTuning for SQL Server

    针对这种情况,人工智能自动SQL优化工具应运而生.现在我就向大家介绍这样一款工具:SQLTuning for SQL Server. 1. SQL Tuning 简介 SQL Turning是Quest公司出品的Quest Central软件中的一个工具. QuestCentral(图1)是一款集成化.图形化.跨平台的数据库管理解决方案,可以同时管理Oracle.DB2 和 SQL server 数据库.它包含了如下的多个工具: 数据库管理(DBA)  数据库监控(Monitoring Pack

随机推荐

其他