摘要：

堆表：又称堆组织表，常用的表类型，以堆的方式管理，当增加数据时，将使用段中第一个适合数据大小的空闲空间。当删除数据时，留下的空间允许以后的DML操作重用。 堆组织表(heap table)

应用中99%(或者更多)的情况下使用的可能都是堆组织表，不过随着IOT的出现，这种状况以后可能会有所改观，因为IOT本身就可以加索引。执行 CREATE TABLE语句时，默认得到的表类型就是堆组织表。如果你想要任何其他类型的表结构，就需要在CREATE语句本身中指定它。

堆 (heap)是计算机科学领域中得到深入研究的一种经典数据结构。它实际上就是一个很大的空间、磁盘或内存区(当然，这里所说的磁盘是指数据库表的相应磁 盘)，会以一种显然随机的方式管理。数据会放在最合适的地方，而不是以某种特定顺序来放置。许多人希望能按数据放入表中的顺序从表中取出数据，但是对于 堆，这是无法保证的。这一点很容易说清楚。 参见：

oracle表类型  http://suntengjiao1.blog.163.com/blog/static/99211088200982522251123/

㈠ HOT和IOT的起源

堆组织表的存储速度因为不用考虑排序, 所以存储速度会比较快. 但是要查找符合某个条件的记录, 就必须得读取全部的记录以便筛选.

而这个时候为了加快查询速度, 索引就出现了, 索引是针对少量特定字段的值拿出来进行排序存储, 并记录在表中的位置,

而因为索引是有序的, 所以就会很容易通过索引查询到具体的记录位置, 然后再根据记录位置直接从表中读取该记录.

同时因为索引的字段较少, 所以索引通常会比其基表小得多.

从上面通过索引访问表记录的方式可以看出, 当要访问的数据量较大时, 通过每一条记录的位置去访问原始记录,

每一条符合条件的记录都需要经过索引访问后再访问基表这样一个复杂的过程, 这会花费很多时间,

同样, 如果不经过索引而直接查询表, 也可能因为表字段太多, 记录较大的情况下把全部的数据读取进来, 这也会花费很多时间.

那怎么办呢?

这个时候就会想到, 如果表中数据本身就是有序的, 这样查询表的时候就可以快速的找到符合条件的记录位置,

而很容易判断符合条件记录的位置, 这样只需要读取一小部分数据出来就可以了, 不需要全表记录都读取出来进行判断.

索引表就这样产生了.当然索引表中插入,更新资料的时候可能会因为需要排序而将数据重组, 这时候数据插入或更新速度会比堆组织表慢一些.

如果堆组织表上有索引, 那么对堆组织表的插入也会因为要修改索引而变慢

我们可以看到堆组织表+索引的方式 与 索引表 都能够实现数据的快速查找, 那为什么不全部采用索引表呢, 这样不是很简单吗?

我能想到的是前者我们可以针对不同的查找条件建立多个索引, 而后者却不行, 后者只能对某一组查询条件有效.

当然了，索引表上查询任何记录都是走索引的, 因为它本身就是索引结构.

当查询条件不符合指定条件时, 必须走 index full sacn , 需要扫描全部索引.

这就是说这时无法利用索引表已经根据某些字段排序的事实.也即排序对于这个查询来说无用.

而符合指定的条件时就会走 index range scan

㈡ 定义

① 堆组织表，其索引中记录了记录所在位置的rowid，查找的时候先找索引，然后再根据索引rowid找到块中的行数据。索引和表数据是分离的

② 索引组织表，其行数据以索引形式存放，因此找到索引，就等于找到了行数据。索引和数据是在一起的

㈢ 查找过程                ① 堆组织表                      一般索引大概3-5层，比如rowid为007，那么要找到007可能会先从第一层找<1000,再在第二层找到<100           然后在第三层找到007(注意这已经是3次I/O)           接着再通过007中标识的rowid去对应的磁盘上读取块中的行数据(第4次I/O)                ② 索引组织表                      前面的步骤同上，但是找到007后，由于数据和索引在一起，因此不必再找什么rowid，直接返回结果了