为什么有时数据库不用索引来查找数据[Oracle防范]

当你应用SQL语言,向数据库公布一条查询语句时,ORACLE将伴随产生一个"履行筹划",也就是该语句将通过何种数据搜索筹划履行,是通过全表扫描、还是通过索引搜索等别的方法.搜索筹划的选用与ORACLE的优化器息息相关.

SQL语句的履行步骤

一条SQL语句的处理历程要经过以下几个步骤.

1 语法解析 解析语句的语法能否符合标准,衡量语句中各表达式的意义.

2 语义解析 查抄语句中触及的全部数据库对象能否存在,且用户有呼应的权限.

3 视图转换 将触及视图的查询语句转换为呼应的对基表查询语句.

4 表达式转换 将复杂的SQL表达式转换为较简单的等效衔接表达式.

5 挑选优化器 差别的优化器普通产生差别的"履行筹划"

6 挑选衔接方法 ORACLE有三种衔接方法,对多表衔接ORACLE可挑选得当的衔接方法.

7 挑选衔接次序 对多表衔接ORACLE挑选哪一对表先衔接,挑选这两表中哪个表做为源数据表.

8 挑选数据的搜索途径 按照以上条件挑选符合的数据搜索途径,如是选用全表搜索还是操纵索引或是其他的方法.

9 运行"履行筹划"

ORACLE的优化器

ORACLE有两种优化器:基于法则的优化器（RBO, Rule Based Optimizer）,和基于代价的优化器（CBO, Cost Based Optimizer）.

RBO自ORACLE 6版以来被采取,有着一套严峻的利用法则,只要你按照它去写SQL语句,无论数据表中的内容怎样,也不会影响到你的"履行筹划",也就是说对数据不"敏感",ORACLE公司已经不再发展这种技术了.

CBO自ORACLE 7版被引入,ORACLE自7版以来采取的很多新技术都是基于CBO的,如星型衔接布列查询,哈希衔接查询,和并行查询等.CBO计算各种大概"履行筹划"的"代价",即cost,从中选用cost最低的筹划,作为实际运行筹划.各"履行筹划"的cost的计算按照,依靠于数据表中数据的统计分布,ORACLE数据库本身对该统计分布并不清楚,必要解析表和相关的索引,才能汇集到CBO所需的数据.

普通而言,CBO所挑选的"履行筹划"都不会比RBO的"履行筹划"差,并且相对而言,CBO对程序员的要求没有RBO那么尖刻,节俭了程序员为了从多个大概的"履行筹划"中挑选一个最优的筹划而耗费的调试时间,但在某些场所下也会存在问题.

较典型的问题有:有时,表明显建有索引,但查询历程明显没有效到相关的索引,招致查询历程耗时冗长,占用资源宏大,问题到底出在哪儿呢?按照以下次序查找,基本上能发现缘由所在.

查找缘由的步骤

首先,我们要肯定数据库运行在何种优化情势下,呼应的参数是:optimizer_mode.可在svrmgrl中运行"show parameter optimizer_mode"来查看.ORACLE V7以来缺省的设置应是"choose",即假如对已解析的表查询的话挑选CBO,不然挑选RBO.假如该参数设为"rule",则不管表能否解析过,一概选用RBO,除非在语句顶用hint强迫.

其次,查抄被索引的列或组合索引的首列能否呈目前PL/SQL语句的WHERE子句中,这是"履行筹划"能用到相关索引的必要条件.

第三,看采取了哪类范例的衔接方法.ORACLE的共有Sort Merge Join（SMJ）、Hash Join（HJ）和Nested Loop Join（NL）.在两张表衔接,且内表的目标列上建有索引时,只有Nested Loop才能有效地操纵到该索引.SMJ即便相关列上建有索引,最多只能因索引的存在,避免数据排序历程.HJ由于须做HASH运算,索引的存在对数据查询速度几近没有影响.

第四,看衔接次序能否答应利用相关索引.假定表emp的deptno列上有索引,表dept的列deptno上无索引,WHERE语句有emp.deptno=dept.deptno条件.在做NL衔接时,emp做为外表,先被拜候,由于衔接机制缘由,外表的数据拜候方法是全表扫描,emp.deptno上的索引明显是用不上,最多在其上做索引全扫描或索引快速全扫描.

第五,能否用到系统数据字典表或视图.由于系统数据字典表都未被解析过,大概招致极差的"履行筹划".但是不要私行对数据字典表做解析,不然大概招致死锁,或系统性能下降.

　　以上是“为什么有时数据库不用索引来查找数据[Oracle防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：