东莞网站推广大全,在百度上做网站有用吗,自己在网站开发的客户怎么联系,中国最近的好消息索引分裂
索引块快写满时就会发生索引分裂#xff0c;索引分裂分为两种情况#xff0c;55和91#xff1a; 索引分裂和enq: TX - index contension等待事件的区别 无论是55还是91#xff0c;都是数据增多后索引的正常行为#xff0c;索引分裂是业务数据量增大导致索引增大…索引分裂
索引块快写满时就会发生索引分裂索引分裂分为两种情况55和91 索引分裂和enq: TX - index contension等待事件的区别 无论是55还是91都是数据增多后索引的正常行为索引分裂是业务数据量增大导致索引增大的正常现象索引放不下了自然要更多的索引块来存放数据基本也没有只有表无索引的情况在初始化数据的场景下才会考虑先插入数据再建索引。索引分裂虽然有一定的资源消耗但是在现在的oracle环境中也是可以很快完成的索引过多的话才会影响插入效率。 而enq: TX - index contension这个等待就不是正常现象了。enq: TX - index contension等待表示SQL在等待正在发生分裂的索引块本质上是DML并发过大且都在等待分裂的索引块。
为什么enq: TX - index contension总是发生在顺序插入的字段上 虽然55分裂和91分裂在真实场景都是由可能的但是enq: TX - index contension等待经常发生在91分裂的情况。因为序列、时间等字段上一般会有索引并且经常发生顺序插入此时最后侧的块一直都是热点块后续的插入一直等待分裂块完成才能插入进去此时便造成了enq: TX - index contension。UUID上一般也有索引为什么没有造成enq: TX - index contension等待因为UUID索引存在无序性插入导致UUID索引分裂也很难有后续插入的UUID值刚好也在这个分裂的索引块上。所以UUID是有索引分裂但不会形成enq等待队列从而出现enq: TX - index contension的情况。
解决办法
注意我们要解决的是索引分裂等待enq: TX - index contension而不是索引分裂本身。解决办法 1.反序索引 索引顺序的存放键值反序索引刚好相反。例如一个’1111 0001’一串数字正序索引会将它排在’0000 0002’后面如果是反序索引它排在’0000 0002’前面。想象一下时间字段本身是最右热点反序后秒、分、时排序在前一个索引块可能包含不同月的同一秒数据这样最右热点块基本不存在了反序索引可以将热点打散到索引各个块上。 局限性需要改造索引可能无法使用索引范围扫描。顺序增长的字段无法用到索引范围扫描例如时间字段。某些场景下的反序键值有可能用到需要具体分析。 语法
CREATE INDEX reveridx ON tablzl (name) REVERSE;2.hash分区索引 在普通表上创建hash分区索引相当于表不变、把索引分区这样最右的热点块打撒到各个分区上。比如建立一个8分区的hash分区索引将索引分成8个segment最右热点有8个减缓了索引分裂问题 局限性需要改造索引会影响索引范围查询的性能需要抉择插入热点和查询效率问题。 等值和IN可以高效使用hash分区索引官方文档原文 Queries involving equality and IN predicates on index partitioning key can efficiently use global hash partitioned index to answer queries quickly 但是范围查找的效率会下降分区越多下降越多分区越多热点缓解越明显这显然是一个平衡选择性问题。经测试分区8个范围查找逻辑读提升也接近8倍。分区后在每个分区内索引仍然是有序的聚簇因子差别不大扫描索引的代价差别不大但是回表的代价加大。如果普通索引一个块内有8条数据指向1个数据块会造成1次逻辑读hash后分别存放在8个分区每个分区1个索引块会造成8次逻辑读。这就是范围扫描索引性能下降的原因。 语法
CREATE INDEX cust_last_name_ix ON customers (cust_last_name)GLOBAL PARTITION BY HASH (cust_last_name)PARTITIONS 4;3.利用分区将索引打散 可以将表分区创建本地索引从而达到打散最右热点的效果 局限性分区键不能是索引字段如果是索引字段就没有意义了需要改造表如果有SQL本身有分区字段不会影响范围扫描的效率
4.降低并发 降低并发是终极武器。索引分裂等待本质就是并发太高了如果没有几十个以上的并发插入一般都不会有索引分裂等待。
5.修改索引块大小 将索引块存放在16、32K的表空间中。这种情况理论上确实会有用因为索引能存放的的数据更多了分裂的情况就更少了。不过需要测试其性能可能还有其他参数需要调整。
6.删掉索引 删除索引也是一个思路。根据业务情况如果这个索引不重要可以把索引删掉或者范围查询大小来做分区表利用分区进行过滤而不是索引
这些情况为什么没用
增加ITL事务槽 索引块的事务槽也可能因为高并发而不够用确实于索引分裂的情况有些相似但是其等待为enq: TX - allocate ITL entry。如果有这个等待能分析到是索引块的就说明索引上有较高的并发同样可以用反序索引、hash分区索引来缓解问题也可考虑修改initrans来解决问题。不过这两个等待的根因还是不同的索引分裂不一定会伴随事务槽问题。调整索引块PCT_FREE PCTFREE表示一个数据块可用空间小于PCTFREE时该数据块不在被记录在FREELIST中即不能插入新数据。考虑两种情况增加PCTFREE和减少PCTFREE。增加PCTFREE只能加剧索引分裂减少PCTFREE看上去有效果原理跟调整索引块大小类似但是真实场景中PCTFREE默认是10%已经很难再调小了调整的效果不会很明显。重建索引减少碎片率 这其实没什么关系它没有解决最右热点块的问题。
参考
https://blog.csdn.net/lihuarongaini/article/details/101299328 https://docs.oracle.com/cd/E11882_01/server.112/e41573/data_acc.htm#PFGRF94786
鸣谢豪桑、用哥
