不可见索引是否由 DML 操作维护?

Is an Invisible index maintained by DML operations?

所以我决定模拟看看发生了什么(我学oracle大概7个月了,可能会出错),我知道在DML操作维护的时候索引是正常的(DML操作引起的索引更新),但是我想检查invisible indexes在维护与否的DML操作中。现在我创建 table =>

create table emin1 ( id number primary key, nomre number );

insert into emin1 values(1,1);
insert into emin1 values(2,1);

首先获取索引名称(我没有创建索引),然后在normal index =>

中使用analyze
SQL> select index_name,table_name  from user_indexes a where table_name = 'EMIN3';

INDEX_NAME      TABLE_NAME
--------------- ---------------
SYS_C008422     EMIN3

analyze index SYS_C008422 validate structure;

SQL> select name, lf_rows,distinct_keys from index_stats;

NAME               LF_ROWS DISTINCT_KEYS
--------------- ---------- -------------
SYS_C008422              2             2

我不知道 index_stats 和 select DISTINCT_KEYS 列中的大多数列(我只知道这个 :))),在静态之后我再次插入 2 行并再次分析 = >

insert into emin1 values(3,1);
insert into emin1 values(4,1);

analyze index SYS_C008422 validate structure;

SQL>  select name, lf_rows,distinct_keys from index_stats;

NAME               LF_ROWS DISTINCT_KEYS
--------------- ---------- -------------
SYS_C008422              4             4

所以在插入操作之后我们看到在 index_stats 中发生了变化(这意味着保持不变)并且在 normal index 之后我将其强制为 invisible index =>

SQL> alter index SYS_C008422 invisible;

Index altered.

插入一些行=>

insert into emin1 values(5,1);
insert into emin1 values(6,1);
insert into emin1 values(7,1);

SQL> analyze index SYS_C008422 validate structure;

Index analyzed.

SQL> select name, lf_rows,distinct_keys from index_stats;

NAME               LF_ROWS DISTINCT_KEYS
--------------- ---------- -------------
SYS_C008422              7             7

所以它又改了,我不知道我在这方面是否正确,但我想知道专家的意见,因为在 google 中搜索了更多关于这个但我找不到明确的答案,我模拟了这个看看 DML 操作中发生了什么,我发现了这种方法,我认为这将帮助更多的初学者。

索引的两个重要属性很容易混淆:

1) 可见性。如您所见,由于 DML,这不会影响索引的底层维护,它只是控制该索引是否有资格在优化器计算出 运行 查询的最佳方式时供优化器使用。 "visibility" 与查看它的 优化器 相关。例如,如果您使一个索引不可见,但该索引被定义为 UNIQUE,那么请放心,如果您尝试插入重复项,该不可见索引仍会引发错误。

2) 可用性。索引也可以设置为 "unusable"。这是数据库在发生 DML 时不再更新索引中的条目的地方。因此,不能简单地使用索引,因为它不再代表索引的真实状态。我们通常使索引不可用,以便在 table 上更有效地执行大型操作。在大型操作结束时,我们需要对该索引发出 REBUILD 以使其重新与(更改的)table 数据对齐,因此它再次可用。

希望对您有所帮助。