为什么索引会比其所对应的表大？

ZALBB

这种情况我没想过，得回去翻翻书！

biti_rainy

你可以做测试

ZALBB

请问：如何测试？

biti_rainy

loop
删除数据
commit;
插入数据
commit;
end loop;

数据使用相同的和不同的分别测试
然后看索引所使用空间的变化

mailme365

我记得索引删除好像是逻辑删除，而创建是物理创建。索引修改是逻辑删除再物理创建。
好像是这样的

chao_ping

Use IOTtable .
This is your final solution.

biti_rainy

使用 IOT table  要谨慎

http://expert.csdn.net/Expert/to ... 3.xml?temp=.6524011

如果你经常访问的数据都包含在 索引中
并且不为 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栋101

SNO        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
7

SNO
----------
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 processed

SQL> analyze table t delete statistics;

表已分析。

SQL> select sno from t;

SNO
----------
20
6
7
8
10
20
6
7
8
8
8

SNO
----------
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 processed

SQL>

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





IOT 在数据静态的时候合适
使用了 IOT 不能有其他索引
因为数据是按该索引进行物理组织的，当你insert数据在排序中间的时候，原有数据物理位置都可能发生变化（因这个原因数据不具有固定rowid,这样也造成该表无法创建其他索引）。这样代价比较大

使用普通的主键，一样可以达到你的效果（做了analyze的话，或者通过hints）
只是这样索引中多了 rowid的存储而已


btw:
如果是使用IOT
当你引用的数据超出 索引包含的列范围
一样得扫描整个行，这样就没有太大意义了

索引本身是排序的，根据索引取出来的数据也是排序的

按我个人的意见
关于 IOT/CLUSTER这些东西，通常不要去使用它，使用的不恰当造成不必要的麻烦

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



现在问题的关键是
这个io的浪费是否影响了你的应用?

通常来说，如果取的结果集小不是问题
但若结果集大，则物理读增加的百分比不会太大，而是逻辑读比较大
（如果根据全局索引取数据则分区实质上没有太大意义）
但若读取结果集占了表记录的百分比比高，则使用索引反而可能降低效率
这个百分比多少跟实际情况有关，可能5%----20% ?

但分区对于通过索引的查询来说，就算是local的索引，也有很多需要注意的问题存在

所以如果你的表在百万级别，则不分区使用索引应该问题不大

只要代码写的不错，IO就不会造成太大的问题

chao_ping

Any technolegy badly implemented will do harm to your system.right?
Since it is primary key, will you do update/delete to the pk?

biti_rainy

IOT 还可能涉及  overflow segment等相关问题
必须要使用者同时也了解这些东西

个人以为：
不能使用其他索引
物理数据存储的排序
始终会造成很多问题的

index 的 split  应该比 IOT 由于insert所产生的问题少一些
至于delete/update,  IOT 也不见得比 index 好

使用原则必须坚持你要清楚这个东西是否适合你的系统！

mengxb001

最初由 biti_rainy 发布
[B]loop
删除数据
commit;
插入数据
commit;
end loop;

数据使用相同的和不同的分别测试
然后看索引所使用空间的变化 [/B]

biti_rainy 你所说的相同数据和不同数据有什么严格的要求，我对自己的测试结果很怀疑，感觉好像没有一定的界限