記得5年前遇到一個SQL。就是一個簡單的兩表關聯。SQL跑了幾乎相同一天一夜，這兩個表都非常巨大。每一個表都有幾十個G。數據量每一個表有20多億，表的字段也特別多。
相信大家也知道SQL慢在哪里了，單個進程的PGA 是絕對放不下幾十個G的數據，這就會導致消耗大量temp tablespace，SQL慢就是慢在temp來回來回來回...的讀寫數據。
遇到這樣的超級大表與超級大表怎么優化呢？這篇文章將告訴你答案。
首先創建2個測試表 t1,t2 數據來自dba_objects
create table t1 as select * from dba_objects;
create table t2 as select * from dba_objects;
我們如果 t1 和 t2 就是 兩個超級大表， 要執行的 SQL： select * from t1,t2 where t1.object_id=t2.object_id;
如果t1 t2 都是幾十個GB 或者更大。 那么你懂的。上面的SQL基本上是跑不出結果的。
有些人在想，開個並行不就得了，用並行 hash hash 算法跑SQL，事實上是不能夠的。原因不多說了。
我們能夠利用MPP數據庫架構(Greenplum/Teradata/vertica)思想。或者是利用HADOOP的思想來對上面的SQL進行優化。
MPP架構/HADOOP架構的非常重要的思想就是把數據分割。把大的數據分割為非常多份小的數據。然后再對小的進行關聯。那速度自然就快了。
在Oracle里面怎么把大數據切成小數據呢。有兩個辦法，一個是分區。另外一個是分表。我這里選擇的是分區，當然了看了這篇文章你也能夠分表。
創建一個表P1。在T1的表結構基礎上多加一個字段HASH_VALUE，而且依據HASH_VALUE進行LIST分區
CREATE TABLE P1(
HASH_VALUE NUMBER,
OWNER VARCHAR2(30),
OBJECT_NAME VARCHAR2(128),
SUBOBJECT_NAME VARCHAR2(30),
OBJECT_ID NUMBER,
DATA_OBJECT_ID NUMBER,
OBJECT_TYPE VARCHAR2(19),
CREATED DATE,
LAST_DDL_TIME DATE,
TIMESTAMP VARCHAR2(19),
STATUS VARCHAR2(7),
TEMPORARY VARCHAR2(1),
GENERATED VARCHAR2(1),
SECONDARY VARCHAR2(1),
NAMESPACE NUMBER,
EDITION_NAME VARCHAR2(30)
)
PARTITION BY list(HASH_VALUE)
(
partition p0 values (0),
partition p1 values (1),
partition p2 values (2),
partition p3 values (3),
partition p4 values (4)
)
相同的。在T2的表結構基礎上多加一個字段HASH_VALUE。而且依據HASH_VALUE進行LIST分區
CREATE TABLE P2(
HASH_VALUE NUMBER,
OWNER VARCHAR2(30),
OBJECT_NAME VARCHAR2(128),
SUBOBJECT_NAME VARCHAR2(30),
OBJECT_ID NUMBER,
DATA_OBJECT_ID NUMBER,
OBJECT_TYPE VARCHAR2(19),
CREATED DATE,
LAST_DDL_TIME DATE,
TIMESTAMP VARCHAR2(19),
STATUS VARCHAR2(7),
TEMPORARY VARCHAR2(1),
GENERATED VARCHAR2(1),
SECONDARY VARCHAR2(1),
NAMESPACE NUMBER,
EDITION_NAME VARCHAR2(30)
)
PARTITION BY list(HASH_VALUE)
(
partition p0 values (0),
partition p1 values (1),
partition p2 values (2),
partition p3 values (3),
partition p4 values (4)
)
注意：P1和P2表的分區必須一模一樣
delete t1 where object_id is null;
commit;
delete t1 where object_id is null;
commit;
insert into p1
select ora_hash(object_id,4), a.* from t1 a; ---工作中用append parallel並行插入
commit;
insert into p2
select ora_hash(object_id,4), a.* from t2 a; ---工作中用append parallel並行插入
commit;
這樣就把 T1 和 T2的表的數據轉移到 P1 和 P2 表中了
那么之前執行的 select * from t1,t2 where t1.object_id=t2.object_id 事實上就等價於以下5個SQL了
select * from p1,p2 where p1.object_id=p2.object_id and p1.hash_value=0 and p2.hash_value=0;
select * from p1,p2 where p1.object_id=p2.object_id and p1.hash_value=1 and p2.hash_value=1;
select * from p1,p2 where p1.object_id=p2.object_id and p1.hash_value=2 and p2.hash_value=2;
select * from p1,p2 where p1.object_id=p2.object_id and p1.hash_value=3 and p2.hash_value=3;
select * from p1,p2 where p1.object_id=p2.object_id and p1.hash_value=4 and p2.hash_value=4;
工作中。大表拆分為多少個分區，請自己推斷。
另外一個須要注意的就是ORA_HASH函數
oracle中的hash分區就是利用的ora_hash函數
partition by hash(object_id) 等價於 ora_hash(object_id,4294967295)
ora_hash(列,hash桶) hash桶默認是4294967295 能夠設置0到4294967295
ora_hash(object_id,4) 會把object_id的值進行hash運算，然后放到 0,1,2,3,4 這些桶里面，也就是說 ora_hash(object_id,4) 僅僅會產生 0 1 2 3 4
有興趣的同學能夠自己去測試速度。
生產庫採用這樣的優化方法，之前須要跑一天一夜的SQL。在1小時內完畢。
為了簡便，能夠使用PLSQL編寫存儲過程封裝上面操作。
當然了，如果使用hadoop 或者 greenplum 有另外的優化方法這里就不做介紹了。
道森出品必屬精品 抄襲翻版必究