关于索引组织表(IOT),请大家帮我看一下!

Question

CU0      NUMBER (6,3)  NOT NULL, 
  CUP0     NUMBER (4,1)  NOT NULL, 
  CI0      NUMBER (6,3)  NOT NULL, 
  CIP0     NUMBER (4,1)  NOT NULL, 
  CU1      NUMBER (6,3)  NOT NULL, 
  CUP1     NUMBER (4,1)  NOT NULL, 
  CI1      NUMBER (6,3)  NOT NULL, 
  CIP1     NUMBER (4,1)  NOT NULL, 
  CU2      NUMBER (6,3)  NOT NULL, 
  CUP2     NUMBER (4,1)  NOT NULL, 
  CI2      NUMBER (6,3)  NOT NULL, 
  CIP2     NUMBER (4,1)  NOT NULL, 
  CU3      NUMBER (6,3)  NOT NULL, 
  CUP3     NUMBER (4,1)  NOT NULL, 
  CI3      NUMBER (6,3)  NOT NULL, 
  CIP3     NUMBER (4,1)  NOT NULL, 
  CU4      NUMBER (6,3)  NOT NULL, 
  CUP4     NUMBER (4,1)  NOT NULL, 
  CI4      NUMBER (6,3)  NOT NULL, 
  CIP4     NUMBER (4,1)  NOT NULL, 
  CU5      NUMBER (6,3)  NOT NULL, 
  CUP5     NUMBER (4,1)  NOT NULL, 
  CI5      NUMBER (6,3)  NOT NULL, 
  CIP5     NUMBER (4,1)  NOT NULL, 
  CU6      NUMBER (6,3)  NOT NULL, 
  CUP6     NUMBER (4,1)  NOT NULL, 
  CI6      NUMBER (6,3)  NOT NULL, 
  CIP6     NUMBER (4,1)  NOT NULL, 
  CU7      NUMBER (6,3)  NOT NULL, 
  CUP7     NUMBER (4,1)  NOT NULL, 
  CI7      NUMBER (6,3)  NOT NULL, 
  CIP7     NUMBER (4,1)  NOT NULL, 
  CU8      NUMBER (6,3)  NOT NULL, 
  CUP8     NUMBER (4,1)  NOT NULL, 
  CI8      NUMBER (6,3)  NOT NULL, 
  CIP8     NUMBER (4,1)  NOT NULL, 
  CU9      NUMBER (6,3)  NOT NULL, 
  CUP9     NUMBER (4,1)  NOT NULL, 
  CI9      NUMBER (6,3)  NOT NULL, 
  CIP9     NUMBER (4,1)  NOT NULL, 
  CU10     NUMBER (6,3)  NOT NULL, 
  CUP10    NUMBER (4,1)  NOT NULL, 
  CI10     NUMBER (6,3)  NOT NULL, 
  CIP10    NUMBER (4,1)  NOT NULL, 
  CU11     NUMBER (6,3)  NOT NULL, 
  CUP11    NUMBER (4,1)  NOT NULL, 
  CI11     NUMBER (6,3)  NOT NULL, 
  CIP11    NUMBER (4,1)  NOT NULL, 
  CU12     NUMBER (6,3)  NOT NULL, 
  CUP12    NUMBER (4,1)  NOT NULL, 
  CI12     NUMBER (6,3)  NOT NULL, 
  CIP12    NUMBER (4,1)  NOT NULL, 
  CU13     NUMBER (6,3)  NOT NULL, 
  CUP13    NUMBER (4,1)  NOT NULL, 
  CI13     NUMBER (6,3)  NOT NULL, 
  CIP13    NUMBER (4,1)  NOT NULL, 
  CU14     NUMBER (6,3)  NOT NULL, 
  CUP14    NUMBER (4,1)  NOT NULL, 
  CI14     NUMBER (6,3)  NOT NULL, 
  CIP14    NUMBER (4,1)  NOT NULL, 
  CU15     NUMBER (6,3)  NOT NULL, 
  CUP15    NUMBER (4,1)  NOT NULL, 
  CI15     NUMBER (6,3)  NOT NULL, 
  CIP15    NUMBER (4,1)  NOT NULL, 
  CU16     NUMBER (6,3)  NOT NULL, 
  CUP16    NUMBER (4,1)  NOT NULL, 
  CI16     NUMBER (6,3)  NOT NULL, 
  CIP16    NUMBER (4,1)  NOT NULL, 
  CU17     NUMBER (6,3)  NOT NULL, 
  CUP17    NUMBER (4,1)  NOT NULL, 
  CI17     NUMBER (6,3)  NOT NULL, 
  CIP17    NUMBER (4,1)  NOT NULL, 
  CU18     NUMBER (6,3)  NOT NULL, 
  CUP18    NUMBER (4,1)  NOT NULL, 
  CI18     NUMBER (6,3)  NOT NULL, 
  CIP18    NUMBER (4,1)  NOT NULL, 
  CU19     NUMBER (6,3)  NOT NULL, 
  CUP19    NUMBER (4,1)  NOT NULL, 
  CI19     NUMBER (6,3)  NOT NULL, 
  CIP19    NUMBER (4,1)  NOT NULL, 
  CU20     NUMBER (6,3)  NOT NULL, 
  CUP20    NUMBER (4,1)  NOT NULL, 
  CI20     NUMBER (6,3)  NOT NULL, 
  CIP20    NUMBER (4,1)  NOT NULL, 
  CU21     NUMBER (6,3)  NOT NULL, 
  CUP21    NUMBER (4,1)  NOT NULL, 
  CI21     NUMBER (6,3)  NOT NULL, 
  CIP21    NUMBER (4,1)  NOT NULL, 
  CU22     NUMBER (6,3)  NOT NULL, 
  CUP22    NUMBER (4,1)  NOT NULL, 
  CI22     NUMBER (6,3)  NOT NULL, 
  CIP22    NUMBER (4,1)  NOT NULL, 
  CU23     NUMBER (6,3)  NOT NULL, 
  CUP23    NUMBER (4,1)  NOT NULL, 
  CI23     NUMBER (6,3)  NOT NULL, 
  CIP23    NUMBER (4,1)  NOT NULL, 
  CU24     NUMBER (6,3)  NOT NULL, 
  CUP24    NUMBER (4,1)  NOT NULL, 
  CI24     NUMBER (6,3)  NOT NULL, 
  CIP24    NUMBER (4,1)  NOT NULL, 
  CU25     NUMBER (6,3)  NOT NULL, 
  CUP25    NUMBER (4,1)  NOT NULL, 
  CI25     NUMBER (6,3)  NOT NULL, 
  CIP25    NUMBER (4,1)  NOT NULL)
由于以下原因,我想将它建成IOT（有无必要？?还是用堆组织表，建一个唯一索引好一些？?）:
(1)经常通过主码访问(前四列)
(2)经常按主码进行时间范围检索
注:此表的操作主要是插入和查询。
但由于行的长度很大,我想使用overflow段(有无必要？？原因？？)，但是是用PCTTHRESHOLD还是INCLUDING呢，
我想把除主码之外的列都放到溢出段中，所以想用INCLUDING。请大家帮我看一下我上面的想法合适否？
并帮我解答括号内的疑问？

Answer 1

如果你经常访问的数据都包含在 索引中
并且不为 null
优化器是可以选择  只扫描索引的，但需要做  analyze 
如果IOT 并不是一个特别好的选择
特别是数据变化频繁的话将造成很大的麻烦窃以为使用索引比较好
SQL> select * from t;SNO        GRADE      ADDRESS
---------- ---------- --------------------------------------------------
20         97215      珠海翠香路松林街2号7栋101
6          97217      珠海翠香路松林街2号7栋101
7          97219      珠海翠香路松林街2号7栋101
8          97221      珠海翠香路松林街2号7栋101
10         97229      珠海翠香路松林街2号7栋101
20         97215      珠海翠香路松林街2号7栋101
6          97217      珠海翠香路松林街2号7栋101
7          97219      珠海翠香路松林街2号7栋101
8          97221      珠海翠香路松林街2号7栋101
8          97223      珠海翠香路松林街2号7栋101
8          97225      珠海翠香路松林街2号7栋101SNO        GRADE      ADDRESS
---------- ---------- --------------------------------------------------
9          97227      珠海翠香路松林街2号7栋101
10         97229      珠海翠香路松林街2号7栋101
20         97215      珠海翠香路松林街2号7栋101
6          97217      珠海翠香路松林街2号7栋101
7          97219      珠海翠香路松林街2号7栋101
8          97221      珠海翠香路松林街2号7栋101
8          97223      珠海翠香路松林街2号7栋101
8          97225      珠海翠香路松林街2号7栋101
9          97227      珠海翠香路松林街2号7栋101已选择20行。SQL> analyze table t compute statistics;表已分析。
SQL> set autotrace on
SQL> select sno from t;SNO
----------
10
10
20
20
20
6
6
6
7
7
7SNO
----------
8
8
8
8
8
8
8
9
9已选择20行。
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=20 Bytes=40)
   1    0   INDEX (FULL SCAN) OF 'T1' (NON-UNIQUE) (Cost=1 Card=20 Byt
          es=40)Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          3  consistent gets
          0  physical reads
          0  redo size
       1111  bytes sent via SQL*Net to client
        536  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         20  rows processedSQL> analyze table t delete statistics;表已分析。SQL> select sno from t;SNO
----------
20
6
7
8
10
20
6
7
8
8
8SNO
----------
9
10
20
6
7
8
8
8
9已选择20行。
Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'T'
Statistics
----------------------------------------------------------
          0  recursive calls
         12  db block gets
          7  consistent gets
          0  physical reads
          0  redo size
       1174  bytes sent via SQL*Net to client
        536  bytes received via SQL*Net from client
          3  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         20  rows processedSQL> 

Answer 2

biti_rainy(biti_rainy) :
首先感谢您总是积极的回答我们初学者的问题。
并且我很赞同你上面的话。
不过我还是不明白：
（1）我的表操作只有插入和查询，应该不算变化很大啊（引：IOT 并不是一个特 别好的选择，特别是数据变化频繁的话将造成很大的麻烦）
（2）因为我经常按主键进行范围搜索，若使用堆表可能记录不会按主键很好的排序，岂不是增加了I/O。
（）按您的理解， 何时用IOT比较合适？

Answer 3

IOT 在数据静态的时候合适
使用了 IOT 不能有其他索引
因为数据是按该索引进行物理组织的，当你insert数据在排序中间的时候，原有数据物理位置都可能发生变化（因这个原因数据不具有固定rowid,这样也造成该表无法创建其他索引）。这样代价比较大使用普通的主键，一样可以达到你的效果（做了analyze的话，或者通过hints）
只是这样索引中多了 rowid的存储而已

Answer 4

btw:
如果是使用IOT
当你引用的数据超出 索引包含的列范围
一样得扫描整个行，这样就没有太大意义了索引本身是排序的，根据索引取出来的数据也是排序的按我个人的意见
关于 IOT/CLUSTER这些东西，通常不要去使用它，使用的不恰当造成不必要的麻烦

Answer 5

biti_rainy(biti_rainy) :
你关于IOT观点，我基本认同，谢谢！
“索引本身是排序的，根据索引取出来的数据也是排序的”
从性能上考虑，虽然根据索引取出来的数据也是排序的，但并不代表记录从物理上也是排序的，所以磁盘I/O会有许多让费，
并且我这个表的记录数是很大的，
那末我使用分区表好不好？？？

Answer 6

现在问题的关键是
这个io的浪费是否影响了你的应用?通常来说，如果取的结果集小不是问题
但若结果集大，则物理读增加的百分比不会太大，而是逻辑读比较大
（如果根据全局索引取数据则分区实质上没有太大意义）
但若读取结果集占了表记录的百分比比高，则使用索引反而可能降低效率
这个百分比多少跟实际情况有关，可能5%----20% ?但分区对于通过索引的查询来说，就算是local的索引，也有很多需要注意的问题存在所以如果你的表在百万级别，则不分区使用索引应该问题不大只要代码写的不错，IO就不会造成太大的问题

Answer 7

分区通常来说更重要的是体现在管理的方便
和 不使用索引的 范围扫描 (当然也可以是把某个或者某个范围的值限制在某些分区以内而避免full table scan)这两个才是真正体现分区的优势的地方说了半天你的数据量和空间使用大小的估计你还是没有给出来

Answer 8

刚刚估算了一下，
我的表的开始记录是100000条，
每条记录长度是：965Byte
记录逐日稳定增加
一年后的记录是：14400000条另：
我经常进行范围搜索，的结果集可能很大，但它在整个表中所占的比例却不大，
我这种情况适合用表分区吗？