通過10104閱讀hash join工作機制 ---Optimal

          Hash Join 執行有三種工作機制: Optimal，onepass, multipass，兩張表進行

hash join，通常是將小表在記憶體中built hash table，另一張表進行filter，hash值匹

配的行，再校驗具體條件是否滿足（因為我們知道hash計算時候，存在hash-

collision問題，這就意味著可能不同的行值，出現相同的hash值，所以必須進行校

驗）。小表在記憶體中搭建hash 表，可能存在記憶體不足的問題，這就出現了上述描述

的三個工作機制，以下的部分是通過event 10104來窺探具體工作機制。


一、概述部分

1、hash area size的總體分配
    
    hash area size = hash_table size + bitmap table size + 管理空間大小

具體體現在跟蹤檔案內容如下：

Original hash-area size: 1009238
--資料庫分配hash-area大小，由引數hash_area_size決定

Memory for slot table: 737280
--實際存放小表hash值的記憶體大小，我們可以把他稱為hash table或者多個partitions

Calculated overhead for partitions and row/slot managers: 271958
--主要包含bitmap表和管理資訊

2、hash table的分配
   
    hash table size = sum(partitions) = N * slots =N * Block_size * Multiblocks IO
     --每個分割槽的大小不一定相同
     --N：表示slot 的數量
    如：hash_table size = 18 * 8*5=720KB = 737280

Number of partitions: 8
--資料庫將hash table的記憶體空間劃分成8個區域

Number of slots: 18
--資料庫的記憶體採用chunk方式管理，分為18個chunks，在跟蹤檔案中以slot或者cluster表示。

Multiblock IO: 5
--hash table的每次IO是5個blocks

Block size(KB): 8
--每個block的大小為8K

Cluster (slot) size(KB): 40
--每個slot的大小是40KB，具體計算：block_size * Multiblock IO = 8*5=40KB

Minimum number of bytes per block: 8160
--每個block最小可用空間為8160

3、bitmap表空間分配情況

Bit vector memory allocation(KB): 32
--bitmap表分配空間為32KB

Per partition bit vector length(KB): 4
--因為有8個partition，所以每個分割槽大小是4K

4、build表的資訊
Maximum possible row length: 577
--最大存放的行數是577，而我們實際所需要build表的行數是500，所以我們可以大概猜測為optimal hash join。

二、Optimal hash join

1、hash表的總述

*** RowSrcId: 1 HASH JOIN BUILD HASH TABLE (PHASE 1) ***
Total number of partitions: 8
--總分割槽表是8個

Number of partitions which could fit in memory: 8
--在記憶體中我們所能裝的分割槽表數量為8，意味著小表能全部放置在記憶體中

Number of partitions left in memory: 8
--留在記憶體中的分割槽表為8

Total number of slots in in-memory partitions: 8
--放在記憶體中分割槽表所用到的slots數量為8，即 8 *40 = 320KB

Total number of rows in in-memory partitions: 500
--放入記憶體中分割槽表的小錶行數是500，意味著小表全部行放入了記憶體分割槽表
 
2、記憶體分割槽表具體存放行數的資訊

### Partition Distribution ###
Partition:0    rows:67         clusters:1      slots:1      kept=1
Partition:1    rows:67         clusters:1      slots:1      kept=1
Partition:2    rows:46         clusters:1      slots:1      kept=1
Partition:3    rows:74         clusters:1      slots:1      kept=1
Partition:4    rows:57         clusters:1      slots:1      kept=1
Partition:5    rows:58         clusters:1      slots:1      kept=1
Partition:6    rows:74         clusters:1      slots:1      kept=1
Partition:7    rows:57         clusters:1      slots:1      kept=1

kept=1：表示該分割槽在記憶體中，如果kept=0表示分割槽表在磁碟中。

Final number of hash buckets: 1024
--hash表由1024個hash bucket來管理

3、hash表的具體存放資訊：

645+282+77+18+2 =1024
### Hash table ###
Number of buckets with   0 rows:        645
Number of buckets with   1 rows:        282
Number of buckets with   2 rows:         77
Number of buckets with   3 rows:         18
Number of buckets with   4 rows:          2
Number of buckets with   5 rows:          0
Number of buckets with   6 rows:          0
Number of buckets with   7 rows:          0
Number of buckets with   8 rows:          0
Number of buckets with   9 rows:          0
Number of buckets with between  10 and  19 rows:          0
Number of buckets with between  20 and  29 rows:          0
Number of buckets with between  30 and  39 rows:          0
Number of buckets with between  40 and  49 rows:          0
Number of buckets with between  50 and  59 rows:          0
Number of buckets with between  60 and  69 rows:          0
Number of buckets with between  70 and  79 rows:          0
Number of buckets with between  80 and  89 rows:          0
Number of buckets with between  90 and  99 rows:          0
Number of buckets with 100 or more rows:          0

--hash表由hash bucket進行管理，從上面資訊我們可以知道500行資料具體分佈資訊：
有282個hash bucket包含1行資料
有77個hash bucket包含2行資料
有18個hash bucket包含3行資料
有2個hash bucket包含4行資料

hash bucket數量=282+77+18+2 = 379

如果hash bucket分佈異常不平均，如某個hash bucket所包含的行數特別多，有可能是小表中參與hash計算join columns的重複的值太多造成，需要重寫語句，剔除該重複值，因為hash bucket下所包含的行數越多，消耗的CPU資源越大。
 
4、hash表的統計資訊：
Total buckets: 1024 Empty buckets: 645 Non-empty buckets: 379
Total number of rows: 500
Maximum number of rows in a bucket: 4
Average number of rows in non-empty buckets: 1.319261

5、大表的使用bitmap進行匹配過濾資訊
Used bitmap filtering: filtered rows=7 minimum required=50 out f=1000
Used bitmap filtering: filtered rows=114 minimum required=50 out f=1000
Used bitmap filtering: filtered rows=258 minimum required=50 out f=1000
Used bitmap filtering: filtered rows=427 minimum required=50 out f=1000
.....................................................

6、以上Optimal工作機制描述

A、先將hash area size 空間分為三部分，第一部分是ORACLE內部管理記憶體；第二部分是將記憶體的hash table分為8個分割槽表，hash table 由hash bucket管理，第三部分是bitmap表；

B、小表在記憶體中構建hash表，先將join columns的數值進行hash function計算，對應的值為hash bucket，如以上案例，進行hash function計算，500行資料，需要379個hash buckets來管理，我手工計算為376個，不知道為什麼計算偏差3個。小表中所需的columns存放到記憶體hash table。hash bucket其所對應的bitmap設定為1。

C、大表在與小表進行hash join時候，先將join columns進行相同的hash function計算，計算結果與bitmap點陣圖進行比對，如果該點陣圖的bit=0，表示對應的hash bucket所管理的記憶體不存在小表rows，因此直接將該行拋棄，如果bit=1，則在對應的hash bucket中找到對應的儲存小錶行，與大表的行按照join columns條件，進行實際列數值匹配，如果匹配，表示該行符合查詢條件，如果不匹配，則直接丟棄。



     

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/354732/viewspace-623359/，如需轉載，請註明出處，否則將追究法律責任。