当前位置:Gxlcms > mysql > 用示例说明索引数据块中出现热块&Latch的场景,并给出解决方案

用示例说明索引数据块中出现热块&Latch的场景,并给出解决方案

时间:2021-07-01 10:21:17 帮助过:51人阅读

引言:索引的热块其实和数据块的热块发生的原理大相径庭,也都是因为大量会话一起访问同一个索引块造成的,我们的解决方案有反向索引,分区索引等。我们说任何一

引言:索引的热块其实和数据块的热块发生的原理大相径庭,也都是因为大量会话一起访问同一个索引块造成的,我们的解决方案有反向索引,分区索引等。我们说任何一种方式都不是完美的,有优点就必然有缺点,我们把包含索引键值的索引块从顺序排列打散到无序排列,香港空间,降低了latch争用,同时也增加了oracle扫描块的数量。我们在实际使用时多测试取长补短,以提高系统的整体性能为目标。


LEO1@LEO1>create table leo1 (id number , name varchar2(200)); 创建了一个leo1表

Table created.

LEO1@LEO1>insert into leo1 (id,name) select object_id,object_name from dba_objects; 将dba_objects前2个字段复制到leo1表中。

71966 rowscreated.

LEO1@LEO1>select id,name from leo1 where rownum<10; 好已经完成

ID NAME

----------------------------------------------------

673 CDC_CHANGE_SOURCES$

674 I_CDC_CHANGE_SOURCES$

675 CDC_CHANGE_SETS$

676 I_CDC_CHANGE_SETS$

677 CDC_CHANGE_TABLES$

678 I_CDC_CHANGE_TABLES$

679 CDC_SUBSCRIBERS$

680 I_CDC_SUBSCRIBERS$

681 CDC_SUBSCRIBED_TABLES$

LEO1@LEO1>create index leo1_index on leo1(id); 在leo1表上id列创建一个索引

Index created.

LEO1@LEO1>execute dbms_stats.gather_table_stats('LEO1','LEO1',cascade=>true); 对表和索引一起做一个分析,香港空间,cascade=>true 指的是级联表上的索引一起做分析

PL/SQL proceduresuccessfully completed.

LEO1@LEO1>create table leo2 (id number,name varchar2(200)); 创建leo2表

Table created.

LEO1@LEO1>insert into leo2 (id,name) select object_id,object_name from dba_objects; 插入71968行

71968 rowscreated.

为什么比leo1表多了2行呢,就是多了leo1和leo1_index这2个对象,我们刚刚建的。

LEO1@LEO1>create index leo2_index on leo2(id) reverse; 创建一个反向索引

Index created.

LEO1@LEO1>execute dbms_stats.gather_table_stats('LEO1','LEO2',cascade=>true); 做分析

PL/SQL proceduresuccessfully completed.

LEO1@LEO1>select index_name,index_type,table_name,status from dba_indexes wheretable_name in ('LEO1','LEO2');

INDEX_NAME INDEX_TYPE TABLE_NAME STATUS

--------------------------------------------------------- ------------------------------ --------

LEO1_INDEX NORMAL LEO1 VALID

LEO2_INDEX NORMAL/REV LEO2 VALID

LEO2_INDEX 是反向索引,我们使用它来把顺序的索引块反向成无序索引块存储,这样我们在查询一个区间范围时,索引键值就会落在不连续的索引块上,防止热块的产生,降低“latch 链表”争用。这可能算是反向索引唯一被使用的情况。因为反向索引不支持index range scan功能,只支持index full scan 全索引扫描,如何理解呢,虚拟主机,举个简单的例子 反向索引 不能帮你检索出 id> 1 and id < 10 的行,但可以帮你检索出 id=10的行,也就是说对范围扫描效率低,等值扫描效率还是很高的。

LEO1@LEO1> set autotrace on; 启动执行计划

LEO1@LEO1>select count(*) from leo1 whereid<100; 这是B-TREE索引执行计划

COUNT(*)

----------

98

Execution Plan

----------------------------------------------------------

Plan hash value:423232053

--------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 5 | 2 (0)| 00:00:01 |

| 1 | SORT AGGREGATE | | 1| 5 | | |

|* 2 | INDEX RANGE SCAN| LEO1_INDEX | 96 | 480 | 2 (0)| 00:00:01 |

--------------------------------------------------------------------------------

索引范围扫描,因为我们查询索引键值都是存放在连续的索引块中,所以只有仅仅的2个一致性读,它只扫描符合条件的索引块就能找到相应的记录。

PredicateInformation (identified by operation id):

---------------------------------------------------

2 - access("ID"<100)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

2 consistent gets

0 physical reads

0 redo size

526 bytes sent via SQL*Net to client

523 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

LEO1@LEO1>select count(*) from leo2 whereid<100; 反向索引执行计划

COUNT(*)

----------

98

Execution Plan

----------------------------------------------------------

Plan hash value:1710468575

------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

------------------------------------------------------------------------------------

人气教程排行