变态方式实现大数据量转换的小表热点盘问题

Posted 2020-10-15 笑扯风云蛋

 

遇到一个认为有点奇怪的问题。

有两个表，大概都是3亿左右的数据，A表有A1字段 B表有B1字段，都是通过其他表来更新的。分别为A1使用C表，B1使用D表，不同的是C表很小只有近1万行，D表很大，也有3亿。（C表后面成为小表，D表成为大表）

 

因为B表有3亿数据，需要从D表这个3亿数据来获取更新，开始的时候我很为这个担心，打算给D表分表来做，但是实际测试了一下，发现居然B更新的比A表快。百思不得其解。去请教DBA，分析后发现存在热点盘问题。

 

因为我更新的时候，都是根据索引字段分模来更新的，每个表都分了50个左右的模，由于更新的时候读小表的时候，每次基本都会读到相同的磁盘，所以就存在热点，而读大表的时候，读到相同磁盘的概率就很低，这样，B表的更新就会比A表快了。

 

虽然有点变扭，但是原因确实应该就是这样。但是如何解决呢？

 

我想到的第一种方式，就是把小表的数据keep进缓存中，也就是说，访问小表的时候，尽快使用数据库的缓存(可以参见https://www.cnblogs.com/Richardzhu/p/3437925.html)

按照这篇文章的指引我将小表搞进了内存中，效率虽然有一点提升，但是效果并不明显。这个原因我还是没想清楚到底为什么。

 

第二种方式，按照DBA的指点，我把小表的pctfree（可以参见https://www.cnblogs.com/linjiqin/archive/2012/01/16/2323320.html）改大，改为了70，这样能够使表存储的更加分散，可能因为我这个表实在太小，这个基本没起啥作用。

 

最后实在是没辙，就想到，既然是分模导致的问题，为啥不直接把这个表按照分模逻辑再拆分？这样，访问的时候就会更加分散，我将小表增加了分模的字段，直接复制了50份，原来索引，增加取模ID建为复合索引。同样再做拆分，将表keep进缓存中。

--表

create table prod_attr_spec_on_mod pctfree 70 as select * from prod_attr_spec where 1=2  ;

alter table prod_attr_spec_on_mod add  TABLE_NAME      VARCHAR2(50);

alter table prod_attr_spec_on_mod add  FUN_NAME      VARCHAR2(100);

alter table prod_attr_spec_on_mod add  PROCESS_MOD_NUM      number;

 

declare

  i number ;

begin

for i in 0..50 loop

  insert into prod_attr_spec_on_mod

  select t.* ,

  \'SERV_ATTR\',\'GET_PRODUCT_ATTR_ID_BY_OLD_ONMOD\',i

   from prod_attr_spec  t  ;

            commit ;

end loop;

end ;

--索引

create index IDX_PRIDATTRIDPRODATTRonmod  on prod_attr_spec_on_mod (attr_id ,PROCESS_MOD_NUM) ;

--keep 进内存

alter table prod_attr_spec_on_mod storage(buffer_pool keep);

alter INDEX IDX_PRIDATTRIDPRODATTRonmod STORAGE (BUFFER_POOL KEEP);

Alter table prod_attr_spec_on_mod cache;

 

--表分析

begin

 dbms_stats.gather_table_stats

          (ownname         =>   \'GJ_USER\',

           tabname         =>   \'prod_attr_spec_on_mod\',

           estimate_percent=> 100,

           method_opt      => \'for all   columns\',

           cascade         => true,

           degree =>16

           );

end ;

 

这样做了以后，效率提升了一倍还多，方法确实是比较变态，但是还是挺实用的。