删除和重新创建索引是否与使用dbms.gather_index_stats具有相同的效果?(是否具有与重建/更新索引相同的效果)
还是这两个完全不同的东西不应该相互比较?
区别在于,收集统计信息会刷新有关当前索引的元数据,而删除和重新创建索引则是删除和重新创建索引。
也许通过一个实例可以很容易地理解它们之间的区别。因此,让我们创建一个表和一个索引:
SQL> create table t23 2 as select object_id as id, object_name as name from user_objects 3 / Table created. SQL> create index i23 on t23(id) 2 / Index created. SQL> select o.object_id, i.last_analyzed, i.distinct_keys 2 from user_objects o 3 join user_indexes i 4 on (i.index_name = o.object_name) 5 where o.object_type = 'INDEX' 6 and i.index_name = 'I23' 7 / OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS ---------- -------------------- -------------------- ------------- 116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39 167 1 row selected. SQL>
由于11g,Oracle在创建索引时会自动收集统计信息。因此,索引创建和最后分析显示了相同的日期时间。在以前的版本中,创建索引后,我们必须显式收集统计信息。 了解更多。
接下来,我们将添加一些数据并刷新统计信息:
SQL> insert into t23 values (9999, 'TEST1') 2 / 1 row created. SQL> insert into t23 values (-8888, 'TEST 2') 2 / 1 row created. SQL> exec dbms_stats.gather_index_stats(user, 'I23') PL/SQL procedure successfully completed. SQL> select o.object_id, i.last_analyzed, i.distinct_keys 2 from user_objects o 3 join user_indexes i 4 on (i.index_name = o.object_name) 5 where o.object_type = 'INDEX' 6 and i.index_name = 'I23' 7 / OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS ---------- -------------------- -------------------- ------------- 116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28 169 1 row selected. SQL>
现在,与统计信息有关的元数据已更改,但索引是相同的数据库对象。而如果我们删除并重新创建索引,则会得到一个新的数据库对象:
SQL> drop index i23 2 / Index dropped. SQL> create index i23 on t23(id) 2 / Index created. SQL> select o.object_id, i.last_analyzed, i.distinct_keys 2 from user_objects o 3 join user_indexes i 4 on (i.index_name = o.object_name) 5 where o.object_type = 'INDEX' 6 and i.index_name = 'I23' 7 / OBJECT_ID CREATED LAST_ANALYZED DISTINCT_KEYS ---------- -------------------- -------------------- ------------- 116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50 169 1 row selected. SQL>
在正常操作中,我们几乎不需要删除并重新创建索引。当加载大量数据以及在极少数情况下发生索引损坏时,此技术有时是合适的。互连网仍然抛出了一些站点,出于性能原因,这些站点建议定期重建索引(也可能是“重新平衡”偏斜的索引),但是这些站点不会提供基准来证明长期收益,并且肯定不会包括时间和成本。重新构建练习浪费了CPU周期。
“我目前正在尝试优化加载和更新大量数据的过程,并思考哪种方法更好”
重建索引比刷新统计信息需要更多的工作。显然是正确的,因为重建包括收集统计信息作为子任务。问题是,与删除索引然后重新创建索引相比,对具有索引的表进行批量DML效率更高。将数据加载到没有索引的表中并随后重新创建它们会更快。
这里没有一成不变的规则:这取决于您有多少索引,在表的整个大小中受影响的行的比例,是否需要索引来强制执行关系完整性约束等等。操作之间也有很大的不同:您可能希望删除大容量插入的索引,但保留它们以进行更新,这取决于WHERE子句所需的索引以及更新是否影响索引列。
简而言之,您需要对自己的特定方案进行基准测试。当涉及性能问题时,这通常是答案。