不可见索引是否由 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 数据对齐,因此它再次可用。
希望对您有所帮助。
所以我决定模拟看看发生了什么(我学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
=>
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 数据对齐,因此它再次可用。
希望对您有所帮助。