删除和重新创建索引是否与使用 dbms.gather_index_stats 具有相同的效果?(它是否与重建/更新索引具有相同的效果)
还是这两种完全不同的东西不应该相互比较?
删除和重新创建索引是否与使用 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 子句需要哪些索引以及更新是否影响索引列。
简而言之,您需要对自己的特定场景进行基准测试。当涉及到性能问题时,这通常是答案。