哈希演算法分區
❶ PHP mysql 實現hash分區的問題
當分片索引不是純整型的字元串時，只接受整型的內置 hash 演算法是無法使用的。為此，stringhash 按照用戶定義的起點和終點去截取分片索引欄位中的部分字元，根據當中每個字元的二進制 unicode 值換算出一個長整型數值，然後就直接調用內置 hash 演算法求解分片路由：先求模得到邏輯分片號，再根據邏輯分片號直接映射到物理分片。
用戶需要在 rule.xml 中定義 partitionLength[] 和 partitionCount[] 兩個數組和 hashSlice 二元組。
在 DBLE 的啟動階段，點乘兩個數組得到模數，也是邏輯分片的數量
並且根據兩個數組的叉乘，得到各個邏輯分片到物理分片的映射表（物理分片數量由 partitionCount[] 數組的元素值之和）
此外根據 hashSlice 二元組，約定把分片索引值中的第 4 字元到第 5 字元（字元串以 0 開始編號，編號 3 到編號 4 等於第 4 字元到第 5 字元）字元串用於 「字元串->整型」的轉換
在 DBLE 的運行過程中，用戶訪問使用這個演算法的表時，WHERE 子句中的分片索引值會被提取出來，取當中的第 4 個字元到第 5 字元，送入下一步
設置一個初始值為 0 的累計值，逐個取字元，把累計值乘以 31，再把這個字元的 unicode 值當成長整型加入到累計值中，如此類推直至處理完截取出來的所有字元，此時的累計值就能夠代表用戶的分片索引值，完成了 「字元串->整型」 的轉換
對上一步的累計值進行求模，得到邏輯分片號
再根據邏輯分片號，查映射表，直接得到物理分片號
- <property name="partitionLength">1</property><property name="partitionCount">2880</property>
- <property name="partitionLength">1,1</property><property name="partitionCount">1440,1440</property>
- <property name="partitionLength">2880</property><property name="partitionCount">1</property>
- <property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>
- <property name="partitionLength">256,512</property><property name="partitionCount">2,1</property>
- <property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>
- <property name="partitionLength">512,256</property><property name="partitionCount">1,2</property>
- <property name="partitionLength">256,512</property><property name="partitionCount">2,1</property>
若希望從首字元開始截取 k 個字元（ k 為正整數），配置的內容形式可以為「 0 : k 」、「 k 」或「 : k 」；
若希望從末字元開始截取 k 個字元（ k 為正整數），則配置的內容形式可以為「 -k : 0 」、「 -k 」或「 -k : 」；
若希望從頭第 m 個字元起算截取 n 個字元（ m 和 n 都是正整數），則先計算出 i = m - 1 和 j = i + n - 1，配置的內容形式為「 i : j 」；
若希望從尾第 m 個字元起算截取從尾算起的 n 個字元（ m 和 n 都是正整數），則先計算出 i = -m + n - 1，配置的內容形式可以為「 -m : i 」；
若希望不截取，則配置的內容形式可以為「 0 : 0 」、「 0 : 」、「 : 0 」或 「 : 」
與MyCat的類似分片演算法對比
兩種演算法在string轉化為int之後，和 hash 分區演算法相同，區別也繼承了 hash 演算法的區別。
開發注意點
【分片索引】1. 必須是字元串
【分片索引】2. 最大物理分片配置方法是，讓 partitionCount[] 數組和等於 2880
例如：
或
【分片索引】3. 最小物理分片配置方法是，讓 partitionCount[] 數組和等於 1
例如
【分片索引】4. partitionLength 和 partitionCount 被當做兩個逗號分隔的一維數組，它們之間的點乘必須在 [1, 2880] 范圍內
【分片索引】5. partitionLength 和 partitionCount 的配置對順序敏感
和
是不同的分片結果
【分片索引】6. 分片索引欄位長度小於用戶指定的截取長度時，截取長度會安全減少到符合分片索引欄位長度
【數據分布】1. 分片索引欄位截取越長則越有利於數據均勻分布
【數據分布】2. 分片索引欄位的內容重復率越低則越有利於數據均勻分布
運維注意點
【擴容】1. 預先過量分片，並且不改變 partitionCount 和 partitionLength 點乘結果，也不改變截取設置 hashSlice 時，可以避免數據再平衡，只需進行涉及數據的遷移
【擴容】2. 若需要改變 partitionCount 和 partitionLength 點乘結果或改變截取設置 hashSlice 時，需要數據再平衡
【縮容】1. 預先過量分片，並且不改變 partitionCount 和 partitionLength 點乘結果，也不改變截取設置 hashSlice 時，可以避免數據再平衡，只需進行涉及數據的遷移
【縮容】2. 若需要改變 partitionCount 和 partitionLength 點乘結果或改變截取設置 hashSlice 時，需要數據再平衡
配置注意點
【配置項】1. 在 rule.xml 中，可配置項為<property name="partitionLength"> 、<property name="partitionCount"> 和 <property name="hashSlice">
【配置項】2.在 rule.xml 中配置 <property name="partitionLength">標簽
內容形式為：<物理分片持有的虛擬分片數>[,<物理分片持有的虛擬分片數>,...<物理分片持有的虛擬分片數>]
物理分片持有的虛擬分片數必須是整型，物理分片持有的虛擬分片數從左到右與同順序的物理分片數對應，partitionLength 和partitionCount 的點乘結果必須在 [1, 2880] 范圍內
【配置項】3. 在 rule.xml 中配置 <property name="partitionCount">標簽
內容形式為：<物理分片數>[,<物理分片數>,...<物理分片數>]
其中物理分片數必須是整型，物理分片數按從左到右的順序與同順序的物理分片持有的虛擬分片數對應，物理分片的編號從左到右連續遞進，partitionLength 和 partitionCount 的點乘結果必須在 [1, 2880] 范圍內
【配置項】4. partitionLength 和 partitionCount 的語義是：持有partitionLength[i] 個虛擬分片的物理分片有 partitionCount[i] 個
例如
語義是持有 512 個邏輯分片的物理分片有 1 個，緊隨其後，持有 256 個邏輯分片的物理分片有 2 個
【配置項】5.partitionLength 和 partitionCount 都對書寫順序敏感，
例如
分片結果是第一個物理分片持有頭512個邏輯分片，第二個物理分片持有緊接著的256個邏輯分片，第三個物理分片持有最後256個邏輯分片，相對的
分片結果則是第一個物理分片持有頭 256 個邏輯分片，第二個物理分片持有緊接著的 256 個邏輯分片，第三個物理分片持有最後 512 個邏輯分片
【配置項】6.partitionLength[] 的元素全部為 1 時，這時候partitionCount 數組和等於 partitionLength 和 partitionCount 的點乘，物理分片和邏輯分片就會一一對應，該分片演算法等效於直接取余
【配置項】7.在 rule.xml 中配置標簽，從分片索引欄位的第幾個字元開始截取到第幾個字元：
❷ hash演算法原理
Hash Join概述 Hash join演算法的一個基本思想就是根據小的row sources(稱作build input，我們記較小的表為S，較大的表為B) 建立一個可以存在於hash area內存中的hash table，然後用大的row sources(稱作probe input) 來探測前面所建的hash table。如果hash area內存不夠大，hash table就無法完全存放在hash area內存中。針對這種情況，Oracle在連接鍵利用一個hash函數將build input和probe input分割成多個不相連的分區（分別記作Si和Bi），這個階段叫做分區階段；然後各自相應的分區，即Si和Bi再做Hash join，這個階段叫做join階段。如果在分區後，針對某個分區所建的hash table還是太大的話，oracle就採用nested-loops hash join。所謂的nested-loops hash join就是對部分Si建立hash table，然後讀取所有的Bi與所建的hash table做連接，然後再對剩餘的Si建立hash table，再將所有的Bi與所建的hash table做連接，直至所有的Si都連接完了。 Hash Join演算法有一個限制，就是它是在假設兩張表在連接鍵上是均勻的，也就是說每個分區擁有差不多的數據。但是實際當中數據都是不均勻的，為了很好地解決這個問題，oracle引進了幾種技術，點陣圖向量過濾、角色互換、柱狀圖，這些術語的具體意義會在後面詳細介紹。 二． Hash Join原理我們用一個例子來解釋Hash Join演算法的原理，以及上述所提到的術語。考慮以下兩個數據集。 S={1,1,1,3,3,4,4,4,4,5,8,8,8,8,10} B={0,0,1,1,1,1,2,2,2,2,2,2,3,8,9,9,9,10,10,11} Hash Join的第一步就是判定小表（即build input）是否能完全存放在hash area內存中。如果能完全存放在內存中，則在內存中建立hash table，這是最簡單的hash join。如果不能全部存放在內存中，則build input必須分區。分區的個數叫做fan-out。Fan-out是由hash_area_size和cluster size來決定的。其中cluster size等於db_block_size * hash_multiblock_io_count，hash_multiblock_io_count在oracle9i中是隱含參數。這里需要注意的是fan-out並不是build input的大小/hash_ara_size，也就是說oracle決定的分區大小有可能還是不能完全存放在hash area內存中。大的fan-out導致許多小的分區，影響性能，而小的fan-out導致少數的大的分區，以至於每個分區不能全部存放在內存中，這也影響hash join的性能。 Oracle採用內部一個hash函數作用於連接鍵上，將S和B分割成多個分區，在這里我們假設這個hash函數為求余函數，即Mod(join_column_value,10)。這樣產生十個分區，如下表. 經過這樣的分區之後，只需要相應的分區之間做join即可（也就是所謂的partition pairs），如果有一個分區為NULL的話，則相應的分區join即可忽略。 在將S表讀入內存分區時，oracle即記錄連接鍵的唯一值，構建成所謂的點陣圖向量，它需要佔hash area內存的5%左右。在這里即為{1,3,4,5,8,10}。 當對B表進行分區時，將每一個連接鍵上的值與點陣圖向量相比較，如果不在其中，則將其記錄丟棄。在我們這個例子中，B表中以下數據將被丟棄 {0,0,2,2,2,2,2,2,9,9,9,9,9}。這個過程就是點陣圖向量過濾。 當S1,B1做完連接後，接著對Si,Bi進行連接，這里oracle將比較兩個分區，選取小的那個做build input，就是動態角色互換，這個動態角色互換發生在除第一對分區以外的分區上面。
❸ oracle什麼時候選擇hash join演算法
Hash Join只能用於相等連接，且只能在CBO優化器模式下。相對於nested loop join，hash join更適合處理大型結果集Hash Join的執行計劃第1個是hash表(build table)，第2個探查表(probe table)，一般不叫內外表，nested loop才有內外表Hash表也就是所謂的內表，探查表所謂的外表
兩者的執行計劃形如：
nested loop
outer table --驅動表
inner table
hash join
build table (inner table) --驅動表
probe table (outer table)
先看一張圖片，大致了解Hash Join的過程：
深入理解Oracle表：三大表連接方式詳解之Hash Join的定義，原理，演算法，成本，模式和點陣圖 - Andy - Andys home下面詳細了解一下Hash Join
一 Hash join概念
Hash join演算法的一個基本思想就是根據小的row sources(稱作build input 也就是前文提到的build table，我們記較小的表為S，較大的表為B)建立一個可以存在於hash area內存中的hash table然後用大的row sources(稱作probe input，也就是前文提到的probe table) 來探測前面所建的hash table如果hash area內存不夠大，hash table就無法完全存放在hash area內存中針對這種情況，Oracle在連接鍵利用一個hash函數將build input和probe input分割成多個不相連的分區分別記作Si和Bi，這個階段叫做分區階段；然後各自相應的分區，即Si和Bi再做Hash join，這個階段叫做join階段如果HASH表太大，無法一次構造在內存中，則分成若干個partition，寫入磁碟的temporary segment，則會多一個寫的代價，會降低效率至於小表的概念，對於 hash join 來說，能容納在 pga 中的 hash table 都可以叫小表，通常比如：
pga_aggregate_target big integer 1073741824hash area size 大體能使用到40多 M ，這樣的話通常可能容納 幾十萬的記錄hash area size預設是2*sort_area_size,我們可以直接修改SORT_AREA_SIZE 的大小，HASH_AREA_SIZE也會跟著改變的如果你的workarea_size_policy=auto，那麼我們只需設定pga_aggregate_target但請記住，這是一個session級別的參數，有時，我們更傾向於把hash_area_size的大小設成驅動表的1.6倍左右驅動表僅僅用於nested loop join 和 hash join，但Hash join不需要在驅動表上存在索引，而nested loop join則迫切需求一兩百萬記錄的表 join上 千萬記錄的表，hash join的通常表現非常好不過，多與少，大與小，很多時候很難量化，具體情況還得具體分析如果在分區後，針對某個分區所建的hash table還是太大的話，oracle就採用nested loop hash join所謂的nested-loops hash join就是對部分Si建立hash table，然後讀取所有的Bi與所建的hash table做連接然後再對剩餘的Si建立hash table，再將所有的Bi與所建的hash table做連接，直至所有的Si都連接完了二 Hash Join原理
考慮以下兩個數據集：
S={1,1,1,3,3,4,4,4,4,5,8,8,8,8,10}
B={0,0,1,1,1,1,2,2,2,2,2,2,3,8,9,9,9,10,10,11}
Hash Join的第一步就是判定小表（即build input）是否能完全存放在hash area內存中如果能完全存放在內存中，則在內存中建立hash table，這是最簡單的hash join如果不能全部存放在內存中，則build input必須分區。分區的個數叫做fan-outFan-out是由hash_area_size和cluster size來決定的。其中cluster size等於db_block_size * _hash_multiblock_io_counthash_multiblock_io_count是個隱藏參數,在9.0.1以後就不再使用了[sql]
sys@ORCL> ed
Wrote file afiedt.buf
1 select a.ksppinm name,b.ksppstvl value,a.ksppdesc description2 from x$ksppi a,x$ksppcv b
3 where a.indx = b.indx
4* and a.ksppinm like '%hash_multiblock_io_count%'
sys@ORCL> /
NAME VALUE DESCRIPTION
------------------------------ ----- ------------------------------------------------------------_hash_multiblock_io_count 0 number of blocks hash join will read/write at onceOracle採用內部一個hash函數作用於連接鍵上，將S和B分割成多個分區在這里我們假設這個hash函數為求余函數，即Mod(join_column_value,10)這樣產生十個分區，如下表:
深入理解Oracle表：三大表連接方式詳解之Hash Join的定義，原理，演算法，成本，模式和點陣圖 - Andy - Andys home經過這樣的分區之後，只需要相應的分區之間做join即可（也就是所謂的partition pairs）如果有一個分區為NULL的話，則相應的分區join即可忽略在將S表讀入內存分區時，oracle即記錄連接鍵的唯一值，構建成所謂的點陣圖向量它需要佔hash area內存的5%左右。在這里即為{1,3,4,5,8,10}
當對B表進行分區時，將每一個連接鍵上的值與點陣圖向量相比較，如果不在其中，則將其記錄丟棄在我們這個例子中，B表中以下數據將被丟棄{0,0,2,2,2,2,2,2,9,9,9,9,9}
這個過程就是點陣圖向量過濾
當S1,B1做完連接後，接著對Si,Bi進行連接
這里oracle將比較兩個分區，選取小的那個做build input，就是動態角色互換這個動態角色互換發生在除第一對分區以外的分區上面三 Hash Join演算法
第1步：判定小表是否能夠全部存放在hash area內存中，如果可以，則做內存hash join。如果不行，轉第二步第2步：決定fan-out數
(Number of Partitions) * C<= Favm *M
其中C為Cluster size，其值為DB_BLOCK_SIZE*HASH_MULTIBLOCK_IO_COUNTFavm為hash area內存可以使用的百分比，一般為0.8左右M為Hash_area_size的大小
第3步：讀取部分小表S，採用內部hash函數(這里稱為hash_fun_1)將連接鍵值映射至某個分區，同時採用hash_fun_2函數對連接鍵值產生另外一個hash值這個hash值用於創建hash table用，並且與連接鍵值存放在一起第4步：對build input建立點陣圖向量
第5步：如果內存中沒有空間了，則將分區寫至磁碟上第6步：讀取小表S的剩餘部分，重復第三步，直至小表S全部讀完第7步：將分區按大小排序，選取幾個分區建立hash table(這里選取分區的原則是使選取的數量最多)第8步：根據前面用hash_fun_2函數計算好的hash值，建立hash table第9步：讀取表B，採用點陣圖向量進行點陣圖向量過濾第10步：對通過過濾的數據採用hash_fun_1函數將數據映射到相應的分區中去，並計算hash_fun_2的hash值第11步：如果所落的分區在內存中，則將前面通過hash_fun_2函數計算所得的hash值與內存中已存在的hash table做連接將結果寫致磁碟上。如果所落的分區不在內存中，則將相應的值與表S相應的分區放在一起第12步：繼續讀取表B，重復第9步，直至表B讀取完畢第13步：讀取相應的(Si,Bi)做hash連接。在這里會發生動態角色互換第14步：如果分區過後，最小的分區也比內存大，則發生nested-loop hash join四 Hash Join的成本
⑴ In-Memory Hash Join
Cost(HJ)=Read(S)+ build hash table in memory(CPU)+Read(B) + Perform In memory Join(CPU)忽略cpu的時間，則：
Cost(HJ)=Read(S)+Read(B)
⑵ On-Disk Hash Join
根據上述的步驟描述，我們可以看出：
Cost(HJ)=Cost(HJ1)+Cost(HJ2)
其中Cost(HJ1)的成本就是掃描S,B表，並將無法放在內存上的部分寫回磁碟，對應前面第2步至第12步Cost(HJ2)即為做nested-loop hash join的成本，對應前面的第13步至第14步其中Cost(HJ1)近似等於Read(S)+Read(B)+Write((S-M)+(B-B*M/S))因為在做nested-loop hash join時，對每一chunk的build input，都需要讀取整個probe input，因此Cost(HJ2)近似等於Read((S-M)+n*(B-B*M/S))，其中n是nested-loop hash join需要循環的次數：n=(S/F)/M一般情況下，如果n大於10的話，hash join的性能將大大下降從n的計算公式可以看出，n與Fan-out成反比例，提高fan-out，可以降低n當hash_area_size是固定時，可以降低cluster size來提高fan-out從這里我們可以看出，提高hash_multiblock_io_count參數的值並不一定提高hash join的性能五 Hash Join的過程
一次完整的hash join如下：
1 計算小表的分區（bucket）數--Hash分桶
決定hash join的一個重要因素是小表的分區（bucket）數這個數字由hash_area_size、hash_multiblock_io_count和db_block_size參數共同決定Oracle會保留hash area的20%來存儲分區的頭信息、hash點陣圖信息和hash表因此，這個數字的計算公式是：
Bucket數=0.8*hash_area_size/(hash_multiblock_io_count*db_block_size)2 Hash計算
讀取小表數據（簡稱為R），並對每一條數據根據hash演算法進行計算Oracle採用兩種hash演算法進行計算，計算出能達到最快速度的hash值（第一hash值和第二hash值）而關於這些分區的全部hash值（第一hash值）就成為hash表3 存放數據到hash內存中
將經過hash演算法計算的數據，根據各個bucket的hash值（第一hash值）分別放入相應的bucket中第二hash值就存放在各條記錄中
4 創建hash點陣圖
與此同時，也創建了一個關於這兩個hash值映射關系的hash點陣圖5 超出內存大小部分被移到磁碟
如果hash area被占滿，那最大一個分區就會被寫到磁碟（臨時表空間）上去任何需要寫入到磁碟分區上的記錄都會導致磁碟分區被更新這樣的話，就會嚴重影響性能，因此一定要盡量避免這種情況2-5一直持續到整個表的數據讀取完畢
6 對分區排序
為了能充分利用內存，盡量存儲更多的分區，Oracle會按照各個分區的大小將他們在內存中排序7 讀取大表數據，進行hash匹配
接下來就開始讀取大表（簡稱S）中的數據
按順序每讀取一條記錄，計算它的hash值，並檢查是否與內存中的分區的hash值一致如果是，返回join數據
如果內存中的分區沒有符合的，就將S中的數據寫入到一個新的分區中，這個分區也採用與計算R一樣的演算法計算出hash值也就是說這些S中的數據產生的新的分區數應該和R的分區集的分區數一樣。這些新的分區被存儲在磁碟（臨時表空間）上8 完全大表全部數據的讀取
一直按照7進行，直到大表中的所有數據的讀取完畢9 處理沒有join的數據
這個時候就產生了一大堆join好的數據和從R和S中計算存儲在磁碟上的分區10 二次hash計算
從R和S的分區集中抽取出最小的一個分區，使用第二種hash函數計算出並在內存中創建hash表採用第二種hash函數的原因是為了使數據分布性更好11 二次hash匹配
在從另一個數據源（與hash在內存的那個分區所屬數據源不同的）中讀取分區數據，與內存中的新hash表進行匹配。返回join數據12 完成全部hash join
繼續按照9-11處理剩餘分區，直到全部處理完畢六 Hash Join的模式
Oracle中，Hash Join也有三種模式：optimal，one-pass，multi-pass⑴ optimal
當驅動結果集生成的hash表全部可以放入PGA的hash area時，稱為optimal，大致過程如下：
① 先根據驅動表，得到驅動結果集
② 在hash area生成hash bulket，並將若干bulket分成一組，成為一個partition，還會生成一個bitmap的列表，每個bulket在上面佔一位③ 對結果集的join鍵做hash運算，將數據分散到相應partition的bulket中當運算完成後，如果鍵值唯一性較高的話，bulket里的數據會比較均勻，也有可能有的桶裡面數據會是空的這樣bitmap上對應的標志位就是0，有數據的桶，標志位會是1④ 開始掃描第二張表，對jion鍵做hash運算，確定應該到某個partition的某個bulket去探測探測之前，會看這個bulket的bitmap是否會1，如果為0，表示沒數據，這行就直接丟棄掉⑤ 如果bitmap為1，則在桶內做精確匹配，判斷OK後，返回數據這個是最優的hash join，他的成本基本是兩張表的full table scan，在加微量的hash運算博客開篇的那幅圖描述的也就是這種情況
⑵ one-pass
如果進程的pga很小，或者驅動表結果集很大，超過了hash area的大小，會怎麼辦？
當然會用到臨時表空間，此時oracle的處理方式稍微復雜點需奧注意上面提到的有個partition的概念可以這么理解，數據是經過兩次hash運算的，先確定你的partition，再確定你的bulket假設hash area小於整個hash table，但至少大於一個partition的size，這個時候走的就是one-pass當我們生成好hash表後，狀況是部分partition留在內存中，其他的partition留在磁碟臨時表空間中當然也有可能某個partition一半在內存，一半在磁碟，剩下的步驟大致如下：
① 掃描第二張表，對join鍵做hash運算，確定好對應的partition和bulket② 查看bitmap，確定bulket是否有數據，沒有則直接丟棄③ 如果有數據，並且這個partition是在內存中的，就進入對應的桶去精確匹配，能匹配上，就返回這行數據，否則丟棄④ 如果partition是在磁碟上的，則將這行數據放入磁碟中暫存起來，保存的形式也是partition，bulket的方式⑤ 當第二張表被掃描完後，剩下的是驅動表和探測表生成的一大堆partition，保留在磁碟上⑥ 由於兩邊的數據都按照相同的hash演算法做了partition和bulket，現在只要成對的比較兩邊partition數據即可並且在比較的時候，oracle也做了優化處理，沒有嚴格的驅動與被驅動關系他會在partition對中選較小的一個作為驅動來進行，直到磁碟上所有的partition對都join完可以發現，相比optimal，他多出的成本是對於無法放入內存的partition，重新讀取了一次，所以稱為one-pass只要你的內存保證能裝下一個partition，oracle都會騰挪空間，每個磁碟partition做到one-pass⑶ multi-pass
這是最復雜，最糟糕的hash join
此時hash area小到連一個partition也容納不下，當掃描好驅動表後可能只有半個partition留在hash area中，另半個加其他的partition全在磁碟上剩下的步驟和one-pass比價類似，不同的是針對partition的處理由於驅動表只有半個partition在內存中，探測表對應的partition數據做探測時如果匹配不上，這行還不能直接丟棄，需要繼續保留到磁碟，和驅動表剩下的半個partition再做join這里舉例的是內存可以裝下半個partition，如果裝的更少的話，反復join的次數將更多當發生multi-pass時，partition物理讀的次數會顯著增加七 Hash Join的點陣圖
這個點陣圖包含了每個hash分區是否有有值的信息。它記錄了有數據的分區的hash值這個點陣圖的最大作用就是，如果probe input中的數據沒有與內存中的hash表匹配上先查看這個點陣圖，以決定是否將沒有匹配的數據寫入磁碟那些不可能匹配到的數據（即點陣圖上對應的分區沒有數據）就不再寫入磁碟八 小結
① 確認小表是驅動表
② 確認涉及到的表和連接鍵分析過了
③ 如果在連接鍵上數據不均勻的話，建議做柱狀圖④ 如果可以，調大hash_area_size的大小或pga_aggregate_target的值⑤ Hash Join適合於小表與大表連接、返回大型結果集的連接
❹ 高手，11g hash分區後的默認排序，是怎麼排的
文檔內容目標解決方案快速重建統計信息的推薦步驟關於收集optimizer統計信息的重要文檔收集對象的統計信息使用足夠大的samplesize收集所有對象的統計信息收集欄位的統計信息/數據非均勻分布列的histogram收集分區對象的GlobalStatistics(全局統計信息)收集SystemStatistics(系統統計信息)從早期版本升級到11g預設設置統計信息收集命令的例子在單一的表收集統計信息收集某一schema下的所有對象的統計信息收集database中所有對象的統計信息:參考適用於:OracleDatabase-EnterpriseEdition-版本11.1.0.6到11.2.0.3[發行版11.1到11.2]OracleDatabase-StandardEdition-版本11.1.0.6到11.2.0.3[發行版11.1到11.2]OracleDatabase-PersonalEdition-版本11.1.0.6到11.2.0.3[發行版11.1到11.2]本文檔所含信息適用於所有平台目標這篇文檔概述了在Oracle11g中收集CBO（CostBasedOptimizer）的統計信息的推薦方法。對於其它版本請參見:Document1226841.1HowTo:註：下面這個文檔中有個標題為""的章節，該章節提供了關於收集統計信息的一些其它建議Document:1380043.解決方案快速重建統計信息的推薦步驟為快速刪除和重建某張表及它的索引的統計信息（包含非均勻分布列的統計信息）,推薦如下：execdbms_stats.delete_table_stats(ownname=>'user_name',-tabname=>'table_name',cascade_indexes=>true);execdbms_stats.gather_table_stats(ownname=>'user_name',-tabname=>'table_name',-estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,-cascade=>true,-method_opt=>'forallcolumnssizeAUTO');隨後我們會解釋這樣推薦的原因。同樣，後邊會有收集統計信息的例子。需要注意的是，從10gR2開始,下邊的方法可以用來恢復統計信息:Document452011.1*關於收集optimizer統計信息的重要文檔這些推薦適用於大多數的資料庫。這些推薦的目的是為了盡可能生成准確的統計信息，為此我們推薦使用的samplesize（采樣率）為100%。這是因為samplesize的減少可能會導致生成的統計信息不準確。一般來說使用100%的samplesize會使收集信息的時間增長，所以需要考慮調整當前使用的maintenancewindow，使統計信息的收集能在一個maintenancewindow完成。如果可能，我們推薦使用預設好的偏好設置使收集不同對象的過程標准化。不同於對不同的對象使用不同的設置，在Database/Schema/Table一級設置默認偏好能使設置集中化，且不需要對不同對象單獨設置。自動統計信息收集操作也會使用設置好的默認偏好。關於如何設置默認偏好請詳見：Document1493227.盡管默認值對大多數系統都適用，如果您發現某些特定設置比默認值更適合您的系統，那麼請自行添加至默認設置中。收集新的optimizer統計信息一般會保持或改進已存在的執行計劃，但是也可能使某些查詢的性能下降。所以從10gR1開始系統默認會保留最近30天的統計信息，這期間如果遇到問題可以用如下方法恢復到之前的統計信息:Document452011.1*收集新的optimizer的統計信息可能使sharedpool中的cursor無效，所以在資料庫負載低的時候執行統計信息收集將是明智的選擇，比如maintenancewindow。除了objectstatistics（比如業務表和索引的統計信息），我們推薦對dictionaryobjects（數據字典對象）也收集統計信息:Document457926.'Fixed'Objects?對於非常大的系統，統計信息的收集會是非常消耗時間和資源的工作。在這種情況下需要小心選擇samplesize的大小，確保在可接受的時間范圍、資源限制和維護窗口內完成收集。請參見以下文檔：Document44961.1StatisticsGathering:對於這種系統，我們也推薦使用基於改變的統計信息的收集，避免重復收集不必要的信息。和10g相比，11g的自動統計信息的過程已經發生了改變，詳見以下文檔：Document237901.-ExamplesDocument756734.111g:(DocID756734.1)Document743507.1WhyHastheGATHER_STATS_JOBbeenremovedin11g?(DocID743507.1)收集對象的統計信息TheCostBasedOptimizer(CBO)是基於統計信息生成特定查詢的執行計劃的。當samplesize減小的時候，基於抽樣出來的樣本可能會生成不同的統計信息，這是因為這些樣本有可能正好是用某些特定的方法錄入的。在11g中，收集統計信息推薦使用定期統計信息收集腳本。在絕大多數情況下系統默認腳本提供的采樣率都是合適的，並兼顧了以下推薦：使用足夠大的samplesize在11g中，對於ESTIMATE_PERCENT，我們建議使用預設的DBMS_STATS.AUTO_SAMPLE_SIZE。Oracle首先會判斷如果對一個表使用100%的samplesize是否能在一個maintenancewindow中收集完。如果能收集完那麼就對這個表使用100%的samplesize，盡管這意味著對這張表收集統計信息的頻率會降低。如果100%的samplesize並不可行，那麼會至少使用30%作為samplesize。11g使用了一種hash演算法來計算統計信息，所以在大多數時候收集信息的性能都是可以接受的。通常，對大部分應用程序而言，相對於數據每天發生的一點點變化，統計信息整體上的准確度更重要一些。這個參數在早期版本的設置請參見之後的文檔。收集所有對象的統計信息確保所有對象（表和索引）都收集了統計信息。這個通過使用CASCADE參數可以很容易的實現。收集欄位的統計信息/數據非均勻分布列的histogram確保所有數據非均勻分布的列都收集了histogram,並且使用METHOD_OPT參數來確保histogram的精度。通常我們推薦使用預設的設置「AUTO」。這意味著如果histogram的存在會有助於生成更准確的執行計劃，DBMS_STATS會自動在需要欄位上生成它。相對於在所有的列上收集histogram，只在確實需要的列上收集是更穩妥的做法。Document390249.1HowToQuicklyAdd/RemoveColumnStatistics(Histograms)ForAColumn注意：假如某個列上的數據是非均勻分布的，並且samplesize不是100%（例如使用AUTO）,那麼這個列上的某些數據可能會被統計信息給漏掉。假如發生了這種情況，並且查詢恰好使用了那些沒有histogrambucket對應的值，那麼這條查詢就不可能使用真正准確的統計信息，進而可能產生不準確甚至是錯誤的執行計劃。在這種情況下，使用100%的samplesize是唯一能保證統計信息准確性的法。假如這是不可行的，移除列上的histogram（只使用列的最大最小值）將使生成的執行計劃更加一致，因為selectivity是不變的。同樣的道理，假如統計信息不是最新的，histogram的存在甚至會引入額外的問題，比如當查詢引用的值是在histogram的范圍之外，或者是」frequence」histogram的中間值(比如，列上添加了一個之前不存在的值或者某個特定值的行數發生了很大的變化）。在這樣的情況下，optimizer將不得不做一些猜測（有可能是不正確的），從而產生不準確的執行計劃。所以，需要通過應用程序測試不同的值以確定哪種統計信息能幫助產生最好的執行計劃。需要注意的是由於功能限制目前只有254個buckets可以用來存儲列統計信息。如果您的distinctvalue的個數非常大而且上面數據的分布是不均勻的，列的統計信息仍然可能是不準確的。詳見:Document212809.還有就是只有當你的應用確實能用到histogram的時候收集它才是有意義的。特別是當你使用綁定變數但不會做窺測(bindpeek)的時候（例如_OPTIM_PEEK_USER_BINDS=FALSE），optimizer不會有任何用來檢索histogram的數據，從而也不會因為histogram的存在而更好地估算cardinality。在早期的版本中，參數METHOD_OPT的預設的設定是"FORALLCOLUMNSSIZE1"。這意味著我們只會收集列的最大最小值，而沒有值的具體分布的信息。我們知道，有些時候histogram的存在反而不利於好的執行計劃的產生，所以當從一個版本升級到另外一個版本後，用戶可能希望先將這個參數設置為之前版本的值，運行一段時間後再調整為當前版本的值，使升級後的初始階段更加平穩，詳見以下文檔：Document465787.1Howto:收集分區對象的GlobalStatistics(全局統計信息)如果使用了partition（分區）技術，時間允許的話盡可能收集GlobalStatistics。GlobalStatistics是非常重要的，但因為涉及數據量及收集時間長度的影響，很多時候它都被略過了。假如不能採用100%的samplesize，那麼我們推薦至少使用1%來做收集。小的采樣（例如0.001,0.0001,0.00001等）可以是非常有效的，但同時要知道大量能幫助optimizer生成准確執行計劃的數據會被忽略掉的。參數ESTIMATE_PERCENT有一個非常彈性的有效的范圍[0.000001->100]，對於非常巨大的表您可以使用非常小的值。不同的系統需要經過測試才能得出最適合這個系統的值。詳見以下文檔:Document236935.1Globalstatistics-AnExplanation11g同時提供了以增量方式收集GlobalStatistics的方法.詳見:(11.1)PartNumberB28274-.3.1.收集SystemStatistics(系統統計信息)收集SystemStatistics來真實反映系統CPU負載情況。除了估算正常I/O部分的cost之外，這些信息會幫助CBO更好的估算CPU部分的cost。詳見：Document470316.1UsingActualSystemStatistics(.(CPUandIO)forCBOusageDocument153761.從早期版本升級到11g如果您是從Oracle的早期版本升級到11g，您可以參見以下關於統計信息管理的建議:Document465787.1Howto:/div>預設設置不同版本收集統計信息時使用的預設設置可能是不一樣的，例如:ESTIMATE_PERCENT的預設值:9i:100%10g:DBMS_STATS.AUTO_SAMPLE_SIZE(使用非常小的估算百分比)11g:DBMS_STATS.AUTO_SAMPLE_SIZE(使用更大的估算百分比-100%)METHOD_OPT:defaults:9i:"FORALLCOLUMNSSIZE1"等同於沒有列值的具體分布信息.10gand11g:"FORALLCOLUMNSSIZEAUTO"-這意味著如果histogram的存在會有助於生成更准確的執行計劃，DBMS_STATS會自動在需要欄位上生成它。在11g中，AUTO_SAMPLE_SIZE的預設值是100%，從而盡可能使統計信息是准確的。在之前的版本上，由於時間的制約，100%的samplesize有時候是不可能的，由於11g實施了一個新的hash演算法避免了傳統的排序（在9i和10g典型慢的部分是排序），這顯著的減少了了收集的時間並提升了資源使用效率。同樣，是否收集列上的統計信息也是自動決定的，總之11g上還有很多其它類似的改進。您可以使用以下文檔中提到的方法來修改默認值:Document1493227.統計信息收集命令的例子在單一的表收集統計信息>execdbms_stats.gather_table_stats(-ownname=>'Schema_name',-tabname=>'Table_name',-estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE,-cascade=>TRUE,-method_opt=>'FORALLCOLUMNSSIZEAUTO');註：如果確定histogram不會對產生更好的執行計劃有幫助，那麼更好的做法是將下邊這一行：method_opt=>'FORALLCOLUMNSSIZEAUTO'替換成method_opt=>'FORALLCOLUMNSSIZE1'註：您需要將'Schema_name'和'Table_name'替換成真正需要收集的schema和table的名字。收集某一schema下的所有對象的統計信息execdbms_stats.gather_schema_stats(-ownname=>'Schema_name',-cascade=>TRUE,-method_opt=>'FORALLCOLUMNSSIZEAUTO');註：將'Schema_name'替換成需要收集的schema的名字。收集database中所有對象的統計信息:execdbms_stats.gather_database_stats(-cascade=>TRUE,-method_opt=>'FORALLCOLUMNSSIZEAUTO');ReferencesNOTE:457926.1-'Fixed'Objects?NOTE:465787.1-Howto:NOTE:236935.1-Globalstatistics-AnExplanationNOTE:237901.1--ExamplesNOTE:44961.1-StatisticsGathering:NOTE:470316.1-UsingActualSystemStatistics(CollectedCPUandIOinformation)NOTE:743507.1-R_STATS_JOBin11g?NOTE:756734.1-11g:NOTE:1226841.1-HowTo:NOTE:1380043.1-(OOW)NOTE:149560.1-(CPUandIO)forCBOuseNOTE:452011.1-*RestoringTableStatistics(Oracle10GOnwards)NOTE:390249.1-HowToQuicklyAdd/RemoveColumnStatistics(Histograms)ForAColumn
❺ 如何使用VeraCrypt創建隱藏分區
使用VeraCrypt創建隱藏分區的方法
准備一份VeraCrypt加密盤文件，加密文件的具體製作方法請參見下面的經驗引用，其中有詳細的說明
如何使用VeraCrypt
進入程序主界面，單擊"加密卷"--"創建加密卷"
隨後彈出創建向導，選擇"創建文件型加密卷"，然後單擊"下一步"
選擇加密盤類型為："隱藏的VeraCrypt加密卷"，單擊"下一步"
選擇創建模式為："直接模式"，單擊"下一步"
加密盤位置設定：單擊"選擇文件"，彈出選擇框，選定你創建好的VeraCrypt加密盤文件，單擊"保存"，回到加密卷位置對話框，單擊"下一步"
輸入原有加密盤密碼，然後單擊"下一步"，之後VeraCrypt會校驗你的原有加密盤密碼並載入加密盤以准備接下來的操作
接下來進入創建加密盤隱藏分區的操作，單擊"下一步"
選擇加密演算法和哈希演算法：保持默認即可，單擊"下一步"
設定隱藏分區大小：依據你創建好的VeraCrypt加密盤文件來操作。比如我的加密盤大小為197MB，我就將隱藏分區大小設定為70MB，設定好後單擊"下一步"
設定隱藏分區密碼：設定一個比較復雜但是容易記憶的密碼，如果你記性不好，你至少要做到字母和數字混合，6-10位密碼即可，然後單擊"下一步"（我的密碼很簡單，只有數字，所以VeraCrypt彈出了提示）
格式化隱藏分區：滑鼠在圖示區域內滑動，直到下方的進度條走滿為止，然後單擊"格式化"，之後隱藏分區就創建完成了
打開隱藏分區：回到VeraCrypt的主界面，選定一個未被佔用的盤符（一般選A:），單擊"選擇文件"，選定剛剛製作好的加密盤文件，單擊"保存"，程序回到主界面，再單擊下面的"載入"
程序要求輸入密碼，記住，要輸入你的隱藏分區密碼，之後單擊"確定"
隱藏分區就載入完成了，雙擊A:盤符選項，隱藏分區就彈出來了，就可以往裡存文件了