对于所有开发工程师（农民工）来说，数据库索引简直就是神器，遇事不决先建立索引再说。先不管建立索引有什么影响，只要有那么一点点的希望，它能够带来sql执行效率的提升，那就是有用，而oracle总是会满足我们大部分的希望，所以索引真的是我们在遇到数据的瓶颈的时候一大非常非常顺手的利器。既然是如此的高效，几乎总能满足我们的愿望，那我们还区了解它干什么？是对oracle的怀疑，还是对自己的不自信，那绝对都不是。我们之所以探究索引，只因为我们只是想简简单单的认识它。
索引是一种数据结构，它可以独立于数据存在，也可以和数据同在。索引的数据结构的唯一目的是为了优化查询的效率，让我们能够更快的找到数据的位置。目前oracle使用的最多的索引数据结构就是b+树，当然还收hash索引之类的，出场率较低。总结回来就是索引是一种使用b+树储存索引键（或包含数据）的数据文件（我们可以通过user_indexes这个表来查看我们建立的索引）。
如果要认识的话，以上应该可以有一个大概的映像了，余下的就是在时间和更多的使用中慢慢探索了吧？这是一门实践的学科。
到此结束显得太过于敷衍，就更加深入的谈一谈数据库中索引的概念吧。抛开oracle个列来说。
索引是一种数据结构，它储存了键和数据的关系。这种关系，如果达到了一种在时间和空间上一致的情况，也就是索引的先后顺序，也是数据物理地址的先后顺序的情况，那么我们称这种索引为聚集索引，聚集索引的数据的物理地址的顺序是和索引的顺序是一致，再次提醒这一点。除了这种关系的其他关系都叫做非聚集索引。那么聚集索引物理地址都是有序的排列的，就可能存在这样的一种情况，我们只存了一个索引的物理地址，后面索引因为是有序的，所以它是靠偏移量来达到它的物理地址的，也就是不是所有索引都存有它的物理地址，它的物理地址是散乱稀疏的保存在几个索引上，这种索引我们叫做稀疏索引，一般聚集索引都是稀疏索引（简称聚集稀疏索引）。另外一种稠密索引，就是说的几乎所有索引都保留有物理地址的情况了，一般它都是非聚集索引，所以一般都是非聚集稠密索引。
以上就是数据库原理里面对于索引的几个概念，这个概念在一定程度上数据库索引和物理地址的关系。
说回oracle的b+树索引（不带数据），我们自建的索引，包括主键，它们都没有保存物理地址，它们都是辅助索引，它们只保留oracle自认的唯一索引rowid（直接保存物理地址）。他们的结构大概就是键值加上rowid就是一个索引的大小。然后存到一个block里面去，直到一个block装满，就在找一个block，当有两个block的时候，他会另外找一个block充当头节点，保存两个block的范围，依此类推，头节点永远只保留范围和block的头地址，所以装满它很难，更上级的更难，所以oracle的所以树一般都很矮1到3层是常见的深度，3层就能够存1000万的数据了，而查询数据实际上只需要读三个block，是不是很快，所以索引一向很快。当然如果你的一个索很大，没几个就装满了block，那就不太好了。甚至可能出现比数据全表还大的情况，那就要注意缩减索引的字段大小和个数了。还有就是索引在更新索引键或插入新数据的时候，会发生索引树的重构，这个过程如果太多了也不好，不能更新过多的索引，比如一个表，你建立了8个索引，每个索引5个字段，只要稍微一插入数据，都要更新8个索引文件，是不是很耗资源。索引一般建议的是联合索引不超过3个，如果有重复出现的字段建议单独建索引（这样可以避免一次数据变动更新几个索引文件），索引数量不要超过5。
索引的几个概念，深度低，查询块。储存键值，体验索引全覆盖的快感。自带排序，在使用统计函数的时候非常的高效。
网友评论