oracle点知识8——索引组织表
关于索引的入门参照博客：http://blog.csdn.net/changyanmanman/article/details/7097318
索引组织表(index organized table, IOT)就是存储在一个索引结构中的表。存储在堆中的表是无组织的(也就是说，只要有可用的空间，数据可以放在任何地方)，IOT中的数据则按主键存储和排序。对你的应用来说，IOT表和一个“常规”表并无二致。
IOT有什么意义呢？使用堆组织表时，我们必须为表和表主键上的索引分别留出空间。而IOT不存在主键的空间开销，因为索引就是数据，数据就是索引，二者已经合二为一。
但是，IOT带来的好处并不止于节约了磁盘空间的占用，更重要的是大幅度降低了I/O,减少了访问缓冲区缓存(尽管从缓冲区缓存获取数据比从硬盘读要快得多，但缓冲区缓存并不免费，而且也绝对不是廉价的。每个缓冲区缓存获取都需要缓冲区缓存的多个闩，而闩是串行化设备，会限制应用的扩展能力)
IOT适用的场合有：
1、完全由主键组成的表。这样的表如果采用堆组织表，则表本身完全是多余的开销，因为所有的数据全部同样也保存在索引里，此时，堆表是没用的。
2、代码查找表。如果你只会通过一个主键来访问一个表，这个表就非常适合实现为IOT.
3、如果你想保证数据存储在某个位置上，或者希望数据以某种特定的顺序物理存储，IOT就是一种合适的结构。
IOT提供如下的好处：
·提高缓冲区缓存效率，因为给定查询在缓存中需要的块更少。
·减少缓冲区缓存访问，这会改善可扩缩性。
·获取数据的工作总量更少，因为获取数据更快。
·每个查询完成的物理I/O更少。
如果经常在一个主键或唯一键上使用between查询，也是如此。如果数据有序地物理存储，就能提升这些查询的性能。
索引组织表的创建格式如下：
create table indexTable(
ID varchar2 ( 10 ),
NAME varchar2 ( 20 ),
constraint pk_id primary key ( ID )
)
organization index ;
注意两点：
● 创建IOT时，必须要设定主键，否则报错。
● 索引组织表实际上将所有数据都放入了索引中。
索引组织表属性
1、OVERFLOW子句(行溢出)
因为所有数据都放入索引，所以当表的数据量很大时，会降低索引组织表的查询性能。此时设置溢出段将主键和溢出数据分开来存储以提高效率。溢出段的设置有两种格式：
PCTTHRESHOLD n ：制定一个数据块的百分比，当行数据占用大小超出时，该行的其他列数据放入溢出段
INCLUDING column_name ：指定列之前的列都放入索引块，之后的列都放到溢出段
● 当行中某字段的数据量无法确定时使用PCTTHRESHOLD。
● 若所有行均超出PCTTHRESHOLD规定大小，则考虑使用INCLUDING。
create table t88(
ID varchar2 ( 10 ),
NAME varchar2 ( 20 ),
constraint pk_id primary key ( ID )
)
organization index
PCTTHRESHOLD 20
overflow tablespace users
INCLUDING name ;
● 如上例所示，name及之后的列必然被放入溢出列，而其他列根据 PCTTHRESHOLD 规则。
与普通的索引一样，索引组织表也可以使用COMPRESS子句进行键压缩以消除重复值。
具体的操作是，在organization index之后加上COMPRESS n子句
● n的意义在于：指定压缩的列数。默认为无穷大。
例如对于数据(1,2,3)、(1,2,4)、(1,2,5)、(1,3,4)、(1,3,5)时
若使用COMPRESS则会将重复出现的(1,2)、(1,3)进行压缩
若使用COMPRESS 1时，只对数据(1)进行压缩
索引组织表的维护
索引组织表可以和普通堆表一样进行INSERT、UPDATE、DELETE、SELECT操作。
可使用ALTER TABLE ... OVERFLOW语句来更改溢出段的属性。
alter table t88 add overflow; --新增一个overflow
● 要ALTER任何OVERVIEW的属性，都必须先定义overflow，若建表时没有可以新增
alter table t88 pctthreshold 15 including name; --调整overflow的参数
alter table t88 initrans 2 overflow initrans 4; --修改数据块和溢出段的initrans特性
● 关于initrans的概念参考 http://space.itpub.net/265709/viewspace-166534
索引组织表的应用
Heap Table 就是一般的表，获取表中的数据是按命中率来得到的。没有明确的先后之分，在进行全表扫描的时候，并不是先插入的数据就先获取。数据的存放也是随机的，当然根据可用空闲的空间来决定。
IOT 就是类似一个全是索引的表，表中的所有字段都放在索引上，所以就等于是约定了数据存放的时候是按照严格规定的，在数据插入以前其实就已经确定了其位置，所以不管插入的先后顺序，它在那个物理上的那个位置与插入的先后顺序无关。这样在进行查询的时候就可以少访问很多blocks，但是插入的时候，速度就比普通的表要慢一些。
适用于信息检索、空间和OLAP程序。
索引组织表的适用情况：
1、 代码查找表。
2、 经常通过主码访问的表。
3、 构建自己的索引结构。
4、 加强数据的共同定位，要数据按特定顺序物理存储。
5、 经常用between…and…对主码或唯一码进行查询。数据物理上分类查询。如一张订单表，按日期装载数据，想查单个客户不同时期的订货和统计情况。
经常更新的表当然不适合IOT，因为oracle需要不断维护索引，而且由于字段多索引成本就大。
如果不是经常使用主键访问表，就不要使用IOT
索引组织表中的二次索引：
在索引表上建立二次索引（secondary index）访问索引组织表的非主键列或者非主键前缀列的性能将得到提高。
oracle为索引组织表建立的二次索引是建立在逻辑ROWID上面的，什么是逻辑rowid呢？其实就是根据索引组织表的主键生成的rowid，它不是存储位置的实际rowid，oracle能够根据这个逻辑rowid进行 物理推测 找到索引项在索引块中的实际（物理）位置。（捋一下思路：二次索引建立在逻辑rowid上，rowid能推测出数据在索引块的实际位置）这样就能访问索引块了。可以省略通过索引主键来访问的步骤，减少I/O.
但是有一个很明显的问题，就是因为索引组织表的数据行没有固定的物理地址，当索引项被移动到新的物理块时，就还需要再执行主键搜索。
对一个常规表来说，通过间接索引（secondary index）访问表数据意味着先扫描间接索引再获取包含所需数据行的数据块（data block）。而对于索引表（index-organized table）来说，通过间接索引访问表数据的步骤依据是否使用物理推测（physical guess），及物理推测的准确度而有所不同：
- 如不使用物理推测，数据访问需要两次索引扫描：首先扫描间接索引，再依据其结果扫描主键索引（primary key index）。
- 如使用物理推测且推测结果准确，数据访问需要首先扫描间接索引，再进行 I/O 操作获取包含所需数据行的数据块。
- 如使用物理推测且推测结果不准确，数据访问需要首先扫描间接索引，并根据物理推测执行 I/O 操作获取了错误的数据块，之后再进行主键索引扫描。
索引组织表的位图索引：
Oracle 支持在分区的（partitioned）或非分区的（nonpartitioned）索引表（index-organized table）上创建位图索引（bitmap index）。为索引表创建位图索引时需要使用一个映射表（mapping table）。
映射表：这个表的存储结构式按照堆组织表存储的，它用来存储索引组织表的逻辑ROWID，具体说来，就是映射表在每一行中存储一个索引组织表的逻辑rowid，这一映射表自己的每一行的物理rowid与索引组织表的逻辑rowid就建立了一一对应的关系。
建立在索引组织表上的位图索引与建立在堆表上的位图索引十分相似，只不过这里索引组织表使用了映射表中的物理rowid，而堆表直接直接使物理rowid与实际数据对应，IOT中间多了一层映射表，每个iot只需一个映射表就把所有的逻辑rowid存储到物理的映射表中。建立在IOT中的上的多个位图可以共用一个映射表。（这里我在想，不管是IOT还是堆组织表，都是根据索引键的值做的位图索引，比如用性别列做索引，有男，女两个位图，搜索的时候不管是IOT还是堆表，都是一样的根据搜索条件去位图置位表里选择，然后堆表直接找到置位对应的物理rowid，IOT通过映射找到逻辑rowid进行访问）
无论是堆表（heap-organized）还是索引表（index-organized），都会使用搜索键（search key）来检索位图索引（bitmap index）。如果在位图索引中找到了符合条件的记录，这个位图索引项（bitmap index entry）将被转换为物理 rowid（physical rowid）。对于堆表，Oracle 将使用此物理 rowid 访问基表（base table）。而对于索引表，Oracle 将使用此物理 rowid 访问映射表（mapping table）得到逻辑 rowid（logical rowid），再通过逻辑 rowid 访问索引表。
索引表（index-organized table）的数据行发生了移动后，不会导致建立在其上的位图索引（bitmap index）失效。数据行移动后会导致使用映射表（mapping table）中某些逻辑 rowid（logical rowid）进行物理推测（physical guess）时不准确。但是索引表仍旧可以通过主键（primary key）访问。
数据段和索引段：http://blog.csdn.net/changyanmanman/article/details/7270361
索引总结：http://blog.csdn.net/changyanmanman/article/details/7337020
