oracle索引失效总结不走索引.docx

oracle索引失效总结不走索引 　　中输入指令查找到占用CPU时间较长的UPDATE语句：　　2.查找到最长时间的UPDATE语句后，执行，点击QueryView查看执行时间　　3.如果时间较长2-3秒以上，查看条件【where后面的内容】例如MSG_ID=B1;找到UPDATE对应的表　　4.开始创建索引：点选对应的需要条件　　将对应的列名选中，建为索引OK　　Oracle索引的使用规则与性能调优　　索引分类　　逻辑上：　　Unique唯一索引　　物理上：　　B-tree：　　Normal正常型B树　　Bitmap位图索引　　索引结构：　　B-tree：　　适合与大量的增、删、改；　　不能用包含OR操作符的查询；　　适合高基数的列　　典型的树状结构；　　每个结点都是数据块；　　大多都是物理上一层、两层或三层不定，逻辑上三层；　　叶子块数据是排序的，从左向右递增；　　在分支块和根块中放的是索引的范围；　　Bitmap:　　适合与决策支持系统；　　做UPDATE代价非常高；　　非常适合OR操作符的查询；　　基数比较少的时候才能建位图索引；　　树型结构：　　索引头　　开始ROWID，结束ROWID　　BITMAP　　每一个BIT对应着一个ROWID，它的值是1还是0，如果是1，表示着BIT对应的ROWID有值；　　B*tree索引的话通常在访问小数据量的情况下比较适用，比如你访问不超过表中数据的5%，当然这只是个相对的比率，适用于一般的情况。bitmap的话在数据仓库中使用较多，用于低基数列，比如性别之类重复值很多的字段，基数越小越好。　　索引就好象一本字典的目录。凭借字典的目录，我们可以非常迅速的找到我们所需要的条目。数据库也是如此。凭借Oracle数据库的索引，相关语句可以迅速的定位记录的位置，而不必去定位整个表。　　虽然说，在表中是否创建索引，不会影响到Oracle数据库的使用，也不会影响数据库语句的使用。这就好像即使字典没有目录的话，用户仍然可以使用它一样。可是，若字典没有目录，那么可想而知，用户要查某个条目的话，其不得不翻遍整本字典。数据库也是如此。若没有建立相关索引的话，则数据库在查询记录的时候，不得不去查询整个表。当表中的记录比较多的时候，其查询效率就会很低。所以，合适的索引，是提高数据库运行效率的一个很好的工具。　　不过，并不是说表上的索引越多越好。过之而不及。故在数据库设计过程中，还是需要为表选择一些合适的索引。宁缺勿滥，这是建立索引时的一个遵循标准。在理论上，虽然一个表可以设置无限的索引。但是，数据库管理员需要知道，表中的索引越多，维护索引所需要的开销也就越大。每当数据表中记录有增加、删除、更新变化的时候，数据库系统都需要对所有索引进行更新。故数据库表中的索引绝对不是多多益善。具体来说，在索引建立上，笔者对大家有如下建议。　　建议一：在基数小的字段上要善于使用位图索引。　　基数是位图索引中的一个基本的定义，它是指数据库表中某个字段内容中不重复的数值。如在员工信息表中的性别字段，一般就只有男跟女两个值，所以，其基数为2;婚姻状况字段的话，则其只有已婚、未婚、离婚三种状态，其基数就为3;民族一览内也是只有有限的几个值。　　对于要查询基数小的字段，如现在用户想查找所有婚姻状况为“已婚”的“女性”时，利用位图索引可以提高查询的效率。这主要是因为标准索引是通过在索引中保存排序过的索引列以及对应的ROWID来实现的。若我们在基数小的列上建立标准索引的话，则其会返回大量的记录。　　而当我们在创建位图索引的时候，在Oracle会对整个表进行扫描，并且会为索引列的　　每个取值建立一个位图。若内容相同，则在位图上会以一个相同的数字表示。此时，若这个字段的基数比较小的话，则若需要实现对整个字段的查询的话，效率就会非常的高。因为此时，数据库只要位图中数字相同的内容找出来即可。　　除了在数据表某列基数比较小的情况下，采用位图索引外，我们往往在一些特殊的情况下，也会建议采用位图索引。最常见的情况是，在Where限制条件中，若我们多次采用AND或者OR条件时，也建议采用位图索引。因为当一个查询饮用了一些部署了位图索引的列的时候，这些位图可以很方便的与AND或者Or运算符操作结合以快速的找出用户所需要的记录。　　但是，这里要注意，不是在条件语句中包含运算符的时候，采用位图索引都能够提供比较高的效率。一般来说，只有AND或者OR运算符的时候，位图索引才会比较具有优势。若此时用户采用大于号或者不等于号作为条件语句中的限制条件的时候，则往往采用标准索引具有更大的优势。　　所以，笔者在数据库设置中，一般只有在三种情况下才采用位图索引。一是列的基数比较小，而有