IOT支持分区，包括范围分区，散列分区和列表分区，但不支持组合分区，以下是测试脚本：

范围分区：

CREATE TABLE iot_range_example

( range_key_column date ,

 object_id         number,

 data             varchar2(20),

  constraint iot_range_pk primary key (range_key_column, object_id)

)

organization index

PARTITION BY RANGE (range_key_column)

( PARTITION part_1 VALUES LESS THAN

       (to_date('01/01/2005','dd/mm/yyyy')),

  PARTITION part_2 VALUES LESS THAN

       (to_date('01/01/2006','dd/mm/yyyy')),

  PARTITION part_3 VALUES LESS THAN

       (MAXVALUE)

)

/

drop table iot_range_example;

散列分区：

CREATE TABLE iot_hash_example

( hash_key_column   date,

 object_id          number,

 data              varchar2(20),

 constraint iot_hash_pk primary key (hash_key_column, object_id)

)

organization index

PARTITION BY HASH (hash_key_column)

( partition part_1,

  partition part_2

)

/

drop table iot_hash_example;

列表分区：

create table iot_list_example

( state_cd   varchar2(2),

  data       varchar2(20),

  constraint iot_list_pk primary key (state_cd)

)

organization index

partition by list(state_cd)

( partition part_1 values ( 'ME', 'NH', 'VT', 'MA' ),

  partition part_2 values ( 'CT', 'RI', 'NY' )

)

/

drop table iot_list_example;

尝试一下组合分区：

CREATE TABLE composite_example

( range_key_column   date,

  hash_key_column    int,

  data               varchar2(20),

  constraint iot_comp_pk primary key (range_key_column, hash_key_column)

)

organization index

PARTITION BY RANGE (range_key_column)

subpartition by hash(hash_key_column) subpartitions 2

(

PARTITION part_1

     VALUES LESS THAN(to_date('01/01/2005','dd/mm/yyyy'))

     (subpartition part_1_sub_1,

      subpartition part_1_sub_2

     ),

PARTITION part_2

    VALUES LESS THAN(to_date('01/01/2006','dd/mm/yyyy'))

    (subpartition part_2_sub_1,

     subpartition part_2_sub_2

    )

)

/

会提示以下错误：

ORA-25198: 仅支持对索引表进行范围, 列表和散列分区。

参考文献：

《Oracle Database Concepts 10g Release 2》

《Oracle 9i&10g编程艺术》

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

假设表A，有5个字段，其中有一个名为ID的字段为主键。日常业务中，经常需要根据ID字段的值，查找该表上其它字段（一个或多个字段，甚至全部字段）上的值。如果我们只在ID列上创建索引，当执行
select id,字段2，字段3，...
from 表A
where id=(>,<,>=,<=等逻辑操作）xxx;
时，如果结果集是少数记录，那么极可能是通过ID列上的索引获取ROWID，然后回表去读取相应ROWID的行记录，以获取其它字段上的信息。如果这种业务很频繁，为了这个回表的操作就可能带来不小的性能提升。所以，我们很自然的会想到用复合索引，把ID列以外的其它列都编进去，这样就不需要回表了，因为索引中这些列都已经有了。但这样一来，索引的大小几乎与表一样大了，相当于在数据库里同时拥有两张表A，只不过一个是根据ID排了序的，一个是未排序的。这时，如果我们用索引组织表，那么数据库就会以索引的方式来保存表A，数据库中只有一张表的空间使用，不仅节省了空间，而且查询的性能上与创建复合索引的方法有近似的提升。
但是，索引组织表也有弱点，由于这种表是以索引的方式来存储表中的数据，所以，索引叶子块中会保存相应行中所有字段的值。若这些字段的长度累计较大时，每个叶子块可以存储的行数就会很少，就会需要更多的叶子块来存储行记录，而叶子块越多，索引的深度（或层级）就越高，每次访问时需要访问的分支块就越多，即一次访问需要访问的总的数据块也就越多。当过多时，就会把消除回表操作所带来的好处抵消，基至有过之而无不及，性能反而会更差。同时，如果索引组织表的主键值经常更改，意味着相应的行就需要在不同的块之间进行移动。如果索引组织表频繁进行增删改，也会像索引那样，引起索引结构的维护工作（比如分支块的分裂，索引层级的增加，以及索引碎片的出现等）增加，也会引起性能的下降。

综上，一般情况下，只有在满足以下条件时，才应该考虑使用索引组织表：
1、表的宽度（即一行的数据长度）有限。
2、表的主键不会或极少更改。
3、表主要用于查询，DML操作较少。
4、大部分的业务需求是根据主键查询行中其它列上的信息。