知识大全 Index of Oracle

Posted 2022-07-16 索引

篇首语：知识是珍贵宝石的结晶，文化是宝石放出来的光泽。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 Index of Oracle相关的知识，希望对你有一定的参考价值。

Index of Oracle 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　索引( Index )是常见的数据库对象它的设置好坏使用是否得当极大地影响数据库应用程序和Database 的性能虽然有许多资料讲索引的用法 DBA 和 Developer 们也经常与它打交道但笔者发现还是有不少的人对它存在误解因此针对使用中的常见问题讲三个问题此文所有示例所用的数据库是 Oracle OPS on HP N series 示例全部是真实数据读者不需要注意具体的数据大小而应注意在使用不同的方法后数据的比较本文所讲基本都是陈词滥调但是笔者试图通过实际的例子来真正让您明白事情的关键　　 一讲索引并非总是最佳选择 　　如果发现Oracle 在有索引的情况下没有使用索引这并不是Oracle 的优化器出错在有些情况下 Oracle 确实会选择全表扫描（Full Table Scan）而非索引扫描（Index Scan）这些情况通常有　　 表未做statistics 或者 statistics 陈旧导致 Oracle 判断失误根据该表拥有的记录数和数据块数实际上全表扫描要比索引扫描更快 　　对第种情况最常见的例子是以下这句sql 语句　　select count(*) from mytable; 　　在未作statistics 之前它使用全表扫描需要读取多个数据块（一个数据块是 k）做了statistics 之后使用的是 INDEX (FAST FULL SCAN) 只需要读取个数据块但是 statistics 做得不好也会导致Oracle 不使用索引　　第种情况就要复杂得多一般概念上都认为索引比表快比较难以理解什么情况下全表扫描要比索引扫描快为了讲清楚这个问题这里先介绍一下Oracle 在评估使用索引的代价（cost）时两个重要的数据 CF(Clustering factor) 和 FF(Filtering factor) 　　CF: 所谓 CF 通俗地讲就是每读入一个索引块要对应读入多少个数据块　　FF: 所谓 FF 就是该sql 语句所选择的结果集占总的数据量的百分比　　大约的计算公式是 FF * (CF + 索引块个数) 由此估计出一个查询如果使用某个索引会需要读入的数据块块数需要读入的数据块越多则 cost 越大 Oracle 也就越可能不选择使用 index （全表扫描需要读入的数据块数等于该表的实际数据块数）　　其核心就是 CF 可能会比实际的数据块数量大 CF 受到索引中数据的排列方式影响通常在索引刚建立时索引中的记录与表中的记录有良好的对应关系 CF 都很小在表经过大量的插入修改后这种对应关系越来越乱 CF 也越来越大此时需要 DBA 重新建立或者组织该索引　　如果某个sql 语句以前一直使用某索引较长时间后不再使用一种可能就是 CF 已经变得太大需要重新整理该索引了　　FF 则是Oracle 根据 statistics 所做的估计比如 mytables 表有万行其主键myid的最小值是最大值是考虑以下sql 语句　　Select * from mytables where myid>= ; 和　　Select * from mytables where myid>= 　　这两句看似差不多的 sql 语句对Oracle 而言却有巨大的差别因为前者的 FF 是 % 而后者的 FF 可能只有 % 如果它的CF 大于实际的数据块数则Oracle 可能会选择完全不同的优化方式而实际上在我们的数据库上的测试验证了我们的预测以下是在HP 上执行时它们的 explain plan: 　　 第一句 　　SQL> select * from mytables where myid>= ; 　　已选择行　　Execution Plan 　　　　 SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Byt es= ) 　　 TABLE ACCESS (FULL) OF MYTABLES (Cost= Card= Byt es= ) 　　Statistics 　　　　 recursive calls 　　 db block gets 　　 consistent gets 　　 physical reads 　　 redo size 　　 bytes sent via SQL*Net to client 　　 bytes received via SQL*Net from client 　　 SQL*Net roundtrips to/from client 　　 sorts (memory) 　　 sorts (disk) 　　 rows processed 　　 第二句 　　Execution Plan 　　　　 SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Bytes= ) 　　 TABLE ACCESS (BY INDEX ROWID) OF MYTABLES (Cost= Card= 　　Bytes= ) 　　 INDEX (RANGE SCAN) OF PK_MYTABLES (UNIQUE) (Cost= Card= ) 　　Statistics 　　　　 recursive calls 　　 db block gets 　　 consistent gets 　　 physical reads 　　 redo size 　　 bytes sent via SQL*Net to client 　　 bytes received via SQL*Net from client 　　 SQL*Net roundtrips to/from client 　　 sorts (memory) 　　 sorts (disk) 　　 rows processed 　　显而易见第句没有使用索引第句使用了主键索引pk_mytables FF的巨大影响由此可见一斑由此想到我们在写sql 语句时如果预先估计一下 FF 你就几乎可以预见到 Oracle 会否使用索引　　 二讲索引也有好坏 　　索引有 B tree 索引 Bitmap 索引 Reverse b tree 索引等最常用的是 B tree 索引 B 的全称是Balanced 其意义是从 tree 的 root 到任何一个leaf 要经过同样多的 level 索引可以只有一个字段（Single column）也可以有多个字段（Composite）最多个字段 I 还支持 Function based index 许多developer 都倾向于使用单列B 树索引　　所谓索引的好坏是指　　索引不是越多越好特别是大量从来或者几乎不用的索引对系统只有损害 OLTP系统每表超过个索引即会降低性能而且在一个sql 中 Oracle 从不能使用超过个索引　　很多时候单列索引不如复合索引有效率　　用于多表连结的字段加上索引会很有作用　　那么在什么情况下单列索引不如复合索引有效率呢？有一种情况是显而易见的那就是当sql 语句所查询的列全部都出现在复合索引中时此时由于 Oracle 只需要查询索引块即可获得所有数据当然比使用多个单列索引要快得多（此时这种优化方式被称为 Index only access path）　　除此之外呢？我们还是来看一个例子吧　　在 HP（Oracle ）上执行以下语句　　select count( ) from mytabs where coid>= and issuedate >= to_date ( yyyy mm dd ) 　　一开始我们有两个单列索引 I_mytabs (coid) I_mytabs (issuedate) 下面是执行情况　　COUNT( ) 　　　　　　Execution Plan 　　　　 SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Bytes= ) 　　 SORT (AGGREGATE) 　　 TABLE ACCESS (BY INDEX ROWID) OF T_MYTABS (Cost= Card 　　= Bytes= ) 　　 INDEX (RANGE SCAN) OF I_MYTABS (NON UNIQUE) (Cost= 　　Card= ) 　　Statistics 　　　　 recursive calls 　　 db block gets 　　 consistent gets 　　 physical reads 　　 redo size 　　 bytes sent via SQL*Net to client 　　 bytes received via SQL*Net from client 　　 SQL*Net roundtrips to/from client 　　 sorts (memory) 　　 sorts (disk) 　　 rows processed 　　可以看到它读取了个数据块来获得所查询的多行　　现在去掉这两个单列索引增加一个复合索引I_mytabs_test ( coid issuedate) 重新执行结果如下　　COUNT( ) 　　　　　　Execution Plan 　　　　 SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Bytes= ) 　　 SORT (AGGREGATE) 　　 INDEX (RANGE SCAN) OF I_MYTABS_TEST (NON UNIQUE) (Cost= Card= Bytes= ) 　　Statistics 　　　　 recursive calls 　　 db block gets 　　 consistent gets 　　 physical reads 　　 redo size 　　 bytes sent via SQL*Net to client 　　 bytes received via SQL*Net from client 　　 SQL*Net roundtrips to/from client 　　 sorts (memory) 　　 sorts (disk) 　　 rows processed 　　可以看到这次只读取了个数据块　　块对块这就是在这个例子中单列索引与复合索引的代价之比这个例子提示我们在许多情况下单列索引不如复合索引有效率　　可以说在索引的设置问题上其实有许多工作可以做正确地设置索引需要对应用进行总体的分析　　 三讲索引再好不用也是白搭 　　抛开前面所说的假设你设置了一个非常好的索引任何傻瓜都知道应该使用它但是Oracle 却偏偏不用那么需要做的第一件事情 cha138/Article/program/Oracle/201311/16841