一条sql的好坏,主要来源两个方面:
- 1、 从数据库层面:取决于优化器所采用的数据访问方式和数据处理的方式决定
- 2、从业务方面来讲:这条sql在业务上是不是一条好的sql
我们以oracle 11g为例子进行分析。
一、数据的访问方式
【没有索引】
如果一张表没有建立索引,那么优化器采用的数据访问方式也会截然不同,这就取决于oracle的数据访问方式,下边列举两种:
- 1、并行访问
- 2、多数据块访问
【有索引】
建立索引的情况,也会有不同的数据访问方式,主要有下面5种:
- 1、唯一索引(index unique scan)
- 2、范围索引扫描(index range scan)
- 3、全索引扫描(index full scan)
- 4、全索引快速扫描(index fast full scan)
- 5、索引跳跃扫描(index skip scan)
二、数据的处理方式
上面列举了几种数据的访问方式,其实像我们日常开发中使用到的排序order by
,分组group by
、统计count
等等操作,都是对数据的一种操作方式,但是,除了这些基本的操作方式之外,我们一般还会对表进行连接join
处理,对于连接这种处理方式,又有下面几种情况:
-
1、
nested loop join
(内部嵌套循环连接) -
2、
hash join
(哈希连接) -
3、
sort merge join
(合并排序连接)
接下来,我们使用测试用例验证上面3种join
数据处理方式,测试SQL用例如下:
-- 删除nestedLoopTest1、nestedLoopTest2表
drop table nestedLoopTest1 ;
drop table nestedLoopTest2 ;
-- 创建nestedLoopTest表
create table nestedLoopTest1
(
id NUMBER(11)
);
commit;
create table nestedLoopTest2
(
id NUMBER(11)
);
commit;
-- 各赋值100条数据
BEGIN
FOR i IN 0..100 LOOP
INSERT INTO nestedLoopTest1(id) VALUES(i);
END LOOP;
END;
commit;
BEGIN
FOR i IN 0..100 LOOP
INSERT INTO nestedLoopTest2(id) VALUES(i);
END LOOP;
END;
commit;
-- 1、hash join 哈希连接,因为此时两张表是并行执行的
xxxxxx
-- 2、nested join 内部嵌套连接,此时t2中id建了索引
xxxxxx
-- 3、两个表的id都建立了索引
复制代码
- 1、
hash join
(哈希连接)
我们继续执行下面sql:
select t1.* from nestedLoopTest1 t1,nestedLoopTest2 t2 where t1.id=t2.id;
复制代码
此时表nestedLoopTest1
和表nestedLoopTest2
中的id
都没有建立索引,因此,我们会看到下面的执行计划:
执行步骤如上图所示,我们可以看到,此时两张表都是全表扫描,然后再进行一次Hash join
,至于hash join
的原理,后面单独学习介绍。
- 2、
nested loop join
(内部嵌套循环连接)
我们继续执行下面sql:
create index nestedLoopTest2index on nestedLoopTest2(id);
select t1.* from nestedLoopTest1 t1,nestedLoopTest2 t2 where t1.id=t2.id;
复制代码
从执行计划中可以看出,首先对表t1
进行全表扫描,然后对索引nestedLoopTest2index
进行range
范围扫描,为什么是范围扫描呢?因为表t1
中的一条记录,可能在表t2
对应多条记录。
对于循环嵌套连接方式,我们可以想象成2个for循环嵌套即可。
另外,当两个表都建立索引时,我们再继续执行下面的sql:
create index nestedLoopTest1index on nestedLoopTest1(id);
select t1.* from nestedLoopTest1 t1,nestedLoopTest2 t2 where t1.id=t2.id;
复制代码
相比上图,表t1
不再是全表扫描了,而是全索引扫描。
- 3、
sort merge join
(合并排序连接)
该链接方式大概的原理就是,判断原表是否排序,如果未排序,则针对关联字段进行排序;判断关联表是否排序,如果未排序,则进行排序,最后将两个排序的表进行合并。
三、oracle执行计划
我们要知道oracle数据是如何数据访问和数据处理的,我们就要看下执行计划,但执行计划又仅仅告诉我们这些信息。
我们登陆上sqlplus,就拿一条最简单的sql进行说明,简单说下我们应该如何看懂执行计划:
select * from emp;
emp
表是oracle自带的员工表,右键点击Explain Plan
,或者按下F5
查看执行计划,如下图:
执行计划最左边的Description
列是比较重要的,它会列出这个sql的一些执行步骤,该列有下面几个查看规则:
- 1、层次不同情况下,越靠右的步骤越先执行;
- 2、层次相同情况下,越上方的结果越先执行;
上图告诉我们,这条语句采用的数据访问方式是:TABLE ACCESS FULL
,也就是全表扫描,我们可能会问,这个emp
表不是有建立索引吗?其实有索引也没有用,因为我们就是要提取整个表的数据,索引没有意义,这也说明一个情况,有索引的表,不一定效率就高,后面会讲到。
对于Cost
这个指标,这是oracle优化器用来衡量这条sql执行的代价有多大,比如需要消耗多少CPU计算资源呀之类的。
下面介绍几种通过索引访问方式的SQL例子
一、唯一索引(index unique scan)
empno
是emp
表的主键,是一个唯一索引,我们执行下面sql语句,查看其执行计划,如下图:
select * from emp where empno=7782
从执行计划中显示的INDEX UNIQUE SCAN
可以看出,这句sql,oracle优化器会执行唯一索引扫描,扫描完索引之后,我们得到索引的值为7782
,然后oracle肯定要去数据文件中去取这条编号对应的数据块返回嘛,因此我们可以看到执行计划中显示了TABLE ACCESS BY INDEX ROWID
,因为索引存的是每一行的id,因此oracle根据rowid这个属性去找对应的数据。
其实去访问数据块取数据这个步骤有时候是没有的,也就是当你只想取其编号empno
而不是*
的时候,执行计划就不会去数据文件中取数据了,也就是步骤2不会有了,因为oracle直接从索引扫描到之后就直接返回索引这个值就行了,没必要去取数据,我们又不需要,验证如下:
select empno from emp where empno=7782
其实我们一般也不会写这样的sql吧,哈哈~~~
二、范围索引扫描(index range scan)
假设我们执行下面sql语句:
select job from emp where empno>7782
其执行计划如下:
从执行计划中可以看出,这种类型的SQL语句,采用的执行方式为index range scan
范围索引扫描。
三、全索引扫描(index full scan)
全索引扫描,顾名思义就是扫描整个索引区域就能确定出执行结果,比如下面sql语句:
select count(*) from emp
我们统计整个表的所有数据个数,直接读索引数据块的个数即可,步骤2为将步骤一的记过进行一个求和,汇总得到一个总数返回。
四、全索引快速扫描(index fast full scan)
我们先用下面语句拷贝一个表并将重命名:
create table emp1 as (select * from emp);
truncate table emp1;
-- 插入1,000,000条数据
BEGIN
FOR I IN 0..1000000 LOOP
INSERT INTO EMP1(EMPNO,ENAME) VALUES(
I,CONCAT('TBL',I));
END LOOP;
END;
复制代码
表建好之后,我们看下下面sql的执行计划,看看当数据量大的时候,这句sql会不会采用index fast full scan
index fast full scan
区别于index full scan
的地方是前者可以一次性读取多个数据块,类似于并行,而后者串行读取。
使用这种执行方式的SQL语句一般是那种可以直接通过索引就能确定出执行结果,比如我们执行下面SQL:
五、索引跳跃扫描(index skip scan)
index skip scan
是oracle 9i之后才提供的索引扫描方式,主要使用来解决组合索引中,where条件使用非前导列查询时,默认采用ACCESS TABLE FULL
全表扫描的缺点。但是使用该特性是有一些限制条件的,主要有下面几个点:
- 1、组合索引前导列唯一值较少(重复值很多)
- 2、数据库采用CBO优化器,且表和索引都经过分析
- 3、where查询条件中不存在组合索引前导列
接下来我们主要验证两个问题:
测试相应的SQL语句如下:
--删除表
drop table student;
commit;
-- 创建Student表
create table STUDENT
(
stuno NUMBER(11),
stuname VARCHAR2(20),
schoolno NUMBER(11),
age NUMBER(3)
);
commit;
-- 创建组合索引
create index stucombindex on student(stuname,schoolno);
commit;
--F5查看执行计划,会看到是ACCESS TABLE FULL全表扫描,stuname是前导列,schoolno为非前导列
select * from student t where t.schoolno=100;
-- 赋值100万条数据
BEGIN
FOR i IN 0..1000000 LOOP
INSERT INTO student(stuno,stuname,schoolno) VALUES(
i,'TBL',i);
END LOOP;
END;
commit;
-- 更新3条数据的前导列为不同值
update student t set t.stuname=concat('s',t.stuno) where mod(t.stuno,10000)=0;
commit;
select count(*),count(distinct stuname) from student;
-- 对表、索引进行分析
analyze table student compute statistics for table for all columns for all indexes;
-- 此处查看执行计划,可看到优化器采用的是index skip scan
select * from student where schoolno = 1000;
复制代码
1、组合索引中,使用非前导列进行查询时,优化器采用的是ACCESS TABLE FULL
全表扫描
首先将上述sql中,倒数第二句SQL注释掉,将会输出如下内容,默认采用全表扫描:
2、验证index skip scan
经过我们的验证,我们可以知道,当我们建立组合索引时,日常开发中,我们尽可能将 __需求经常用到、选择性高重复值少__的列作为前导列,这样才能最大程度减少非引导列不走索引或者只走跳跃索引的情况。另外我们什么时候建立组合索引呢?主要考虑下面几种情况:
- 1、当单条件查询时,返回较多数据
- 2、当符合条件查询时,返回数据较少
当且仅当条件1和条件2同时成立时,我们这个时候可以建立组合索引了,举个例子,员工表employee
中,age=28
这个条件的人非常多,role=Java程序员
这个条件返回的数据也非常多,但是age=28 and role=Java程序员
返回的数据却非常少!
单条件指:where xxx=xxx
复合条件指:where xxx=xxx and xxx1=xxx1