|
重建索引到底要不要排序？有人说要因为创建索引时需要排序有人说不要因为重建索引的时候可以直接扫描旧的索引来重建成新的索引让我们来看一下rebuild index到底需不需要排序 SQL> select namestatistic# from v$statname where name like %sort%; NAME STATISTIC# sorts (memory) sorts (disk) sorts (rows) 看一下排序操作相关的 stat号 再看一下rebuild index 的执行路径 SQL> explain plan for alter index ind_test_id rebuild; Explained SQL> @?/rdbms/admin/utlxpls PLAN_TABLE_OUTPUT
| Id| Operation|Name| Rows| Bytes | Cost|
| | ALTER INDEX STATEMENT|| | | | | |INDEX BUILD NON UNIQUE| IND_TEST_ID| | | | | | SORT CREATE INDEX|| | | | | |INDEX FAST FULL SCAN| IND_TEST_ID| | | |
执行下rebuild 看看 SQL> select STATISTIC#value from v$mystat where STATISTIC# in(); STATISTIC#VALUE SQL> alter index ind_test_id rebuild; Index altered SQL> select STATISTIC#value from v$mystat where STATISTIC# in(); STATISTIC#VALUE 可以看出sort(memory)增加了一次 为什么要排序呢？因为rebuild index的时候走的index ffs而ffs搜索的顺序是根据 leaf block 的物理存储顺序相关而跟键值的逻辑顺序无关（在index full scan vs fast index full scan这篇文章中有详细介绍） 所以ffs的结果必须再做一次排序 此外在rebulid index online的时候走的是full table scan这时候也是需要排序的而且排序的次数会比较多 在测试中发现每次做rebuild online产生（g中为）次sort(memory)可能跟一些递规排序有关系g里面重建索引排序又有了一些改变在事件的跟蹤文件里面出现Reopened sort目前暂时不知道是什么意思希望有朋友能就这个问题进行探讨 |
