rebuild index 为啥还排序

显示全部楼层 · 2007-10-20 08:38:44

rebuild 应该是从原索引读数据进行index fast full scan , 这些数据是已经sort 过的了，为啥 rebuild 的时候还要进行sort 呢？

千问 · 2007-10-20 08:38:44

rebuild index 应该用index
rebuild index online会走full table scan

千问 · 2007-10-20 08:38:44

原帖由 waityou81 于 2009-8-12 13:06 发表
rebuild index 应该用index
rebuild index online会走full table scan
这个我清楚，我是不理解为啥 rebuild 还要进行sort ，因为数据在索引里已经是sort 过的了，那 rebuild 应该不需要sort 了，但实际情况是它确实还在进行sort 占用大量的临时表空间

千问 · 2007-10-20 08:38:44

rebuild index对原有的索引数据结构进行重建，使原来可能不紧凑，不连贯的索引数据结构保持连贯，也就是已排序。rebuild index相当于创建了一和原来索引名称相同的索引，那创建过程中排序是很自然的了。

千问 · 2007-10-20 08:38:44

原帖由 aks5201314 于 2009-8-12 13:26 发表
rebuild index对原有的索引数据结构进行重建，使原来可能不紧凑，不连贯的索引数据结构保持连贯，也就是已排序。rebuild index相当于创建了一和原来索引名称相同的索引，那创建过程中排序是很自然的了。

创建的过程是从表中读数据，也就是full table scan ,因为表中的数据很有可能不是排过序的，这个时候是要进行sort 的，如果数据是排过序的可以加nosort ，但rebuild 不一样
它不是从表中读数据，是从原索引读数据的，应该是已经排过顺序的，应该不排序才对
期待有人答复

千问 · 2007-10-20 08:38:44

重新创建索引有个排序的过程,使原来可能不紧凑，不连贯的索引数据结构保持连贯，也就是排序

千问 · 2007-10-20 08:38:44

如果你经常对创建索引的表进行DML操作的话，那索引数据结构就很可能不是顺序的，在对表更新的时候索引也会更新，那如何保证在很多DML操作的时候索引还保持原来的顺序的呢？这也是为什么要定期的对有大量的DML操作的表重建索引的原因，重建的时候完全有可能后来INSERT的数据索引键列的值比原有的键列的值小的可能，如果不进行重新排序，那又怎么能保证重建后的索引就一定是排序过的呢？

千问 · 2007-10-20 08:38:44

index full scan和index fast full scan的区别就是,排序问题,因为没走index full scan所以必然要排序,但是我尝试了很多修改统计信息的方法,还是没法让oracle在rebuild索引的时候走index full scan

千问 · 2007-10-20 08:38:44

原帖由 aks5201314 于 2009-8-12 14:09 发表
如果你经常对创建索引的表进行DML操作的话，那索引数据结构就很可能不是顺序的，在对表更新的时候索引也会更新，那如何保证在很多DML操作的时候索引还保持原来的顺序的呢？这也是为什么要定期的对有大量的DML操作的表重建索引的原因，重建的时候完全有可能后来INSERT的数据索引键列的值比原有的键列的值小的可能，如果不进行重新排序，那又怎么能保证重建后的索引就一定是排序过的呢？

你这个说法是错误的，因为索引的数据是顺序增长的，也就是从左向右增长，如果有数据被删除了那么仅是被标记为删除而不是实际删除，索引数据的顺序是ORACLE 自己维护的，棉花糖说的
有一定道理，但为什么会这样呢？ ORACLE 在设计rebuild 的时候没考虑过这些吗？

千问 · 2007-10-20 08:38:44

索引本身是有序,但是index fast full scan并不是按照索引的结构来扫描,而是把索引当作表来扫描,所以是无法保证有序
ps:先去理解下index fast full scan和index full scan的区别吧