在我们传统的印象中，索引和表是两个不同的东西。我们总是先创建表，然后
根据查询，建立相应的索引。表和索引在物理上属于不同的存储空间。
例如你建立了一个好友的通讯录，你经常需要通过指定好友的姓名来查询他的
有关信息，为了提高查询的性能（假设你的好友多如牛毛），你可能希望在他们的
姓名上建立一个索引，这是一种非常自然的想法。
可是，也许有一天你发现，除了上述的这种查询之外，你几乎从不做其他的查
询。你有没有想过，能不能把表的数据直接存放在索引中？这就是本文要讨论的索
引表（Index-Organized Table）。
什么是索引表？就是表本身实际上就是按照索引来组织的，它们在物理上使用
同一存储空间。索引表在物理上可能就是一棵B+树，只不过索引中的每项不再仅仅
是索引属性（如好友姓名），而是表中的一条记录。你在创建表的时候，实际上是
创建了一个索引，所有对普通表的查询仍然可以作用于索引表，而且你仍然可以在
索引表上建立基于其它属性的索引。换句话说，除了创建之外，对索引表和普通表
的操作没有任何差别。
采用索引表的优点是能够提高特定查询的性能。例如你再按照好友姓名查询，
如果是普通索引，则系统首先根据索引找到满足条件的记录的位置（ROWID），再
根据该位置在表中找到对应的记录；而如果是索引表，则可以直接根据索引找出该
记录。
虽然采用索引表，索引和表在物理上不再需要单独存放，但索引表未必就能节
省存储空间（想想这是为什么，注意：B+树的空间利用率实在不高）。
索引表的主要问题是当表被更新时的系统开销较大。想象一下，如果你采用的
是在表上建立索引，那么当你更新表中的记录时，你需要相应地更新它在索引中的
位置，这可能是一种常用的B+树操作；而当你使用索引表时，你也需要完成同样的
操作，但是索引表可能比普通索引要大得多，因此这一操作的开销可能也比前者大
得多（当然这不是绝对的）。
索引表的另一个缺点是不够灵活。你一旦创建了索引表，对用户而言，就相当
于你在创建表的同时也创建了相应的索引。而对普通表而言，用户（或系统）可以
根据需要决定是否应该建立索引（参见《如何使用索引》一文），即使建立了索引，也可以再将其删除。