在執(zhí)行計(jì)劃的開發(fā)過(guò)程中，轉(zhuǎn)換和選擇有這個(gè)不同的任務(wù)；實(shí)際上，在一個(gè)查詢進(jìn)行完語(yǔ)法和權(quán)限檢查后，首先發(fā)生通稱為“查詢轉(zhuǎn)換”的步驟，這里會(huì)進(jìn)行一系列查詢塊的轉(zhuǎn)換，然后才是“優(yōu)選”（優(yōu)化器為了決定最終的執(zhí)行計(jì)劃而為不同的計(jì)劃計(jì)算成本從而選擇最終的執(zhí)行計(jì)劃）。
我們知道查詢塊是以SELECT關(guān)鍵字區(qū)分的，查詢的書寫方式?jīng)Q定了查詢塊之間的關(guān)系，各個(gè)查詢塊通常都是嵌在另一個(gè)查詢塊中或者以某種方式與其相聯(lián)結(jié)；例如：
復(fù)制代碼 代碼如下:
select * from employees where department_id in (select department_id from departments)
就是嵌套的查詢塊，不過(guò)它們的目的都是去探索如果改變查詢寫法會(huì)不會(huì)提供更好的查詢計(jì)劃。
這種查詢轉(zhuǎn)換的步驟對(duì)于執(zhí)行用戶可以說(shuō)是完全透明的，要知道轉(zhuǎn)換器可能會(huì)在不改變查詢結(jié)果集的情況下完全改寫你的SQL語(yǔ)句結(jié)構(gòu)，因此我們有必要重新評(píng)估自己的查詢語(yǔ)句的心理預(yù)期，盡管這種轉(zhuǎn)換通常來(lái)說(shuō)都是好事，為了獲得更好更高效的執(zhí)行計(jì)劃。
我們現(xiàn)在來(lái)討論一下幾種基本的轉(zhuǎn)換：
1.視圖合并
2.子查詢解嵌套
3.謂語(yǔ)前推
4.物化視圖查詢重寫
一、視圖合并
這種方式比較容易理解，它會(huì)將內(nèi)嵌的視圖展開成一個(gè)獨(dú)立處理的查詢塊，或者將其與查詢剩余部分合并成一個(gè)總的執(zhí)行計(jì)劃，轉(zhuǎn)換后的語(yǔ)句基本上不包含視圖了。
視圖合并通常發(fā)生在當(dāng)外部查詢塊的謂語(yǔ)包括：
1，能夠在另一個(gè)查詢塊的索引中使用的列
2，能夠在另一個(gè)查詢塊的分區(qū)截?cái)嘀兴褂玫牧?br />
3，在一個(gè)聯(lián)結(jié)視圖能夠限制返回行數(shù)的條件
在這種查詢器的轉(zhuǎn)換下，視圖并不總會(huì)有自己的子查詢計(jì)劃，它會(huì)被預(yù)先分析并通常情況下與查詢的其他部分合并以獲得性能的提升，如下例。
復(fù)制代碼 代碼如下:
SQL> set autotrace traceonly explain
-- 進(jìn)行視圖合并
SQL> select * from EMPLOYEES a,
2 (select DEPARTMENT_ID from EMPLOYEES) b_view
3 where a.DEPARTMENT_ID = b_view.DEPARTMENT_ID(+)
4 and a.SALARY > 3000;
Execution Plan
----------------------------------------------------------
Plan hash value: 1634680537
----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3161 | 222K| 3 (0)| 00:00:01 |
| 1 | NESTED LOOPS OUTER| | 3161 | 222K| 3 (0)| 00:00:01 |
|* 2 | TABLE ACCESS FULL| EMPLOYEES | 103 | 7107 | 3 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 31 | 93 | 0 (0)| 00:00:01 |
----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("A"."SALARY">3000)
3 - access("A"."DEPARTMENT_ID"="DEPARTMENT_ID"(+))
-- 使用NO_MERGE防止視圖被重寫
SQL> select * from EMPLOYEES a,
2 (select /*+ NO_MERGE */DEPARTMENT_ID from EMPLOYEES) b_view
3 where a.DEPARTMENT_ID = b_view.DEPARTMENT_ID(+)
4 and a.SALARY > 3000;
Execution Plan
----------------------------------------------------------
Plan hash value: 1526679670
-----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3161 | 253K| 7 (15)| 00:00:01 |
|* 1 | HASH JOIN RIGHT OUTER| | 3161 | 253K| 7 (15)| 00:00:01 |
| 2 | VIEW | | 107 | 1391 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | EMPLOYEES | 107 | 321 | 3 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL | EMPLOYEES | 103 | 7107 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("A"."DEPARTMENT_ID"="B_VIEW"."DEPARTMENT_ID"(+))
4 - filter("A"."SALARY">3000)
出于某些情況，視圖合并會(huì)被禁止或限制，如果在一個(gè)查詢塊中使用了分析函數(shù)，聚合函數(shù)，，集合運(yùn)算（如union，intersect，minux），order by子句，以及rownum中的任何一種，這種情況都會(huì)發(fā)生；盡管如此，我們?nèi)匀豢梢允褂?*+ MERGE(v) */提示來(lái)強(qiáng)制使用視圖合并，不過(guò)前提一定要保證返回的結(jié)果集是一致的！?。∪缦吕?/p>
復(fù)制代碼 代碼如下:
SQL> set autotrace on
-- 使用聚合函數(shù)avg導(dǎo)致視圖合并失效
SQL> SELECT e1.last_name, e1.salary, v.avg_salary
2 FROM hr.employees e1,
3 (SELECT department_id, avg(salary) avg_salary
4 FROM hr.employees e2
5 GROUP BY department_id) v
6 WHERE e1.department_id = v.department_id AND e1.salary > v.avg_salary;
Execution Plan
----------------------------------------------------------
Plan hash value: 2695105989
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 17 | 697 | 8 (25)| 00:00:01 |
|* 1 | HASH JOIN | | 17 | 697 | 8 (25)| 00:00:01 |
| 2 | VIEW | | 11 | 286 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 11 | 77 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1605 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E1"."DEPARTMENT_ID"="V"."DEPARTMENT_ID")
filter("E1"."SALARY">"V"."AVG_SALARY")
--使用/*+ MERGE(v) */強(qiáng)制進(jìn)行視圖合并
SQL> SELECT /*+ MERGE(v) */ e1.last_name, e1.salary, v.avg_salary
2 FROM hr.employees e1,
3 (SELECT department_id, avg(salary) avg_salary
4 FROM hr.employees e2
5 GROUP BY department_id) v
6 WHERE e1.department_id = v.department_id AND e1.salary > v.avg_salary;
Execution Plan
----------------------------------------------------------
Plan hash value: 3553954154
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 165 | 5610 | 8 (25)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | HASH GROUP BY | | 165 | 5610 | 8 (25)| 00:00:01 |
|* 3 | HASH JOIN | | 3296 | 109K| 7 (15)| 00:00:01 |
| 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 2889 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL| EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
二、子查詢解嵌套
最典型的就是子查詢轉(zhuǎn)變?yōu)楸磉B接了，它和視圖合并的主要區(qū)別就在于它的子查詢位于where子句，由轉(zhuǎn)換器進(jìn)行解嵌套的檢測(cè)。
下面便是一個(gè)子查詢==>表連接的例子：
復(fù)制代碼 代碼如下:
SQL> select employee_id, last_name, salary, department_id
2 from hr.employees
3 where department_id in
4 (select department_id
5 from hr.departments where location_id > 1700);
Execution Plan
----------------------------------------------------------
Plan hash value: 432925905
---------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 34 | 884 | 4 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 34 | 884 | 4 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 4 | 28 | 2 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | DEPT_LOCATION_IX | 4 | | 1 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 10 | | 0 (0)| 00:00:01 |
| 6 | TABLE ACCESS BY INDEX ROWID | EMPLOYEES | 10 | 190 | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("LOCATION_ID">1700)
5 - access("DEPARTMENT_ID"="DEPARTMENT_ID")
-- 使用/*+ NO_UNNEST */強(qiáng)制為子查詢單獨(dú)生成執(zhí)行計(jì)劃
SQL> select employee_id, last_name, salary, department_id
2 from hr.employees
3 where department_id in
4 (select /*+ NO_UNNEST */department_id
5 from hr.departments where location_id > 1700);
Execution Plan
----------------------------------------------------------
Plan hash value: 4233807898
--------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 10 | 190 | 14 (0)| 00:00:01 |
|* 1 | FILTER | | | | | |
| 2 | TABLE ACCESS FULL | EMPLOYEES | 107 | 2033 | 3 (0)| 00:00:01 |
|* 3 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 1 | 7 | 1 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | DEPT_ID_PK | 1 | | 0 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter( EXISTS (SELECT /*+ NO_UNNEST */ 0 FROM "HR"."DEPARTMENTS"
"DEPARTMENTS" WHERE "DEPARTMENT_ID"=:B1 AND "LOCATION_ID">1700))
3 - filter("LOCATION_ID">1700)
4 - access("DEPARTMENT_ID"=:B1)
可以看到?jīng)]有執(zhí)行子查詢解嵌套的查詢只使用了FILTER來(lái)進(jìn)行兩張表的匹配，謂語(yǔ)信息第一步的查詢也沒有絲毫的改動(dòng)，這便意味著對(duì)于EMPLOYEES表中返回的107行的每一行，都需要執(zhí)行一次子查詢。雖然在oracle中存在子查詢緩存的優(yōu)化，我們無(wú)法判斷這兩種計(jì)劃的優(yōu)劣，不過(guò)相比NESTED LOOPS，F(xiàn)ILTER運(yùn)算的劣勢(shì)是很明顯的。
如果包含相關(guān)子查詢，解嵌套過(guò)程一般會(huì)將相關(guān)子查詢轉(zhuǎn)換成一個(gè)非嵌套視圖，然后與主查詢中的表x相聯(lián)結(jié)，如：
復(fù)制代碼 代碼如下:
SQL> select outer.employee_id, outer.last_name, outer.salary, outer.department_id
2 from hr.employees outer
3 where outer.salary >
4 (select avg(inner.salary)
5 from hr.employees inner
6 where inner.department_id = outer.department_id);
Execution Plan
----------------------------------------------------------
Plan hash value: 2167610409
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 17 | 765 | 8 (25)| 00:00:01 |
|* 1 | HASH JOIN | | 17 | 765 | 8 (25)| 00:00:01 |
| 2 | VIEW | VW_SQ_1 | 11 | 286 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 11 | 77 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS FULL| EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 2033 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("ITEM_1"="OUTER"."DEPARTMENT_ID")
filter("OUTER"."SALARY">"AVG(INNER.SALARY)")
上面的查詢是將子查詢轉(zhuǎn)換成視圖在與主查詢進(jìn)行hash join，轉(zhuǎn)換后的查詢其實(shí)像這樣：
復(fù)制代碼 代碼如下:
SQL> select outer.employee_id, outer.last_name, outer.salary, outer.department_id
2 from hr.employees outer,
3 (select department_id,avg(salary) avg_sal from hr.employees group by department_id) inner
4 where inner.department_id = outer.department_id and outer.salary > inner.avg_sal;
其實(shí)這兩個(gè)語(yǔ)句的執(zhí)行計(jì)劃也是一致
三、謂語(yǔ)前推
將謂詞從內(nèi)部查詢塊推進(jìn)到一個(gè)不可合并的查詢塊中，這樣可以使得謂詞條件更早的被選擇，更早的過(guò)濾掉不需要的數(shù)據(jù)行，提高效率，同樣可以使用這種方式允許某些索引的使用。
復(fù)制代碼 代碼如下:
-- 謂語(yǔ)前推示例
SQL> set autotrace traceonly explain
SQL> SELECT e1.last_name, e1.salary, v.avg_salary
2 FROM hr.employees e1,
3 (SELECT department_id, avg(salary) avg_salary
4 FROM hr.employees e2
5 GROUP BY department_id) v
6 WHERE e1.department_id = v.department_id
7 AND e1.salary > v.avg_salary
8 AND e1.department_id = 60;
Execution Plan
----------------------------------------------------------
Plan hash value: 3521487559
-----------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 41 | 3 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 1 | 41 | 3 (0)| 00:00:01 |
| 3 | VIEW | | 1 | 26 | 2 (0)| 00:00:01 |
| 4 | HASH GROUP BY | | 1 | 7 | 2 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 5 | 35 | 2 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 5 | | 1 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 5 | | 0 (0)| 00:00:01 |
|* 8 | TABLE ACCESS BY INDEX ROWID | EMPLOYEES | 1 | 15 | 1 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - access("DEPARTMENT_ID"=60)
7 - access("E1"."DEPARTMENT_ID"=60)
8 - filter("E1"."SALARY">"V"."AVG_SALARY")
-- 不進(jìn)行謂語(yǔ)前推
SQL> SELECT e1.last_name, e1.salary, v.avg_salary
2 FROM hr.employees e1,
3 (SELECT department_id, avg(salary) avg_salary
4 FROM hr.employees e2
5 WHERE rownum > 1 -- rownum等于同時(shí)使用了no_merge和no_push_pred提示，這會(huì)同時(shí)禁用視圖合并和謂語(yǔ)前推
6 GROUP BY department_id) v
7 WHERE e1.department_id = v.department_id
8 AND e1.salary > v.avg_salary
9 AND e1.department_id = 60;
Execution Plan
----------------------------------------------------------
Plan hash value: 3834222907
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 3 | 123 | 7 (29)| 00:00:01 |
|* 1 | HASH JOIN | | 3 | 123 | 7 (29)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| EMPLOYEES | 5 | 75 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | EMP_DEPARTMENT_IX | 5 | | 1 (0)| 00:00:01 |
|* 4 | VIEW | | 11 | 286 | 4 (25)| 00:00:01 |
| 5 | HASH GROUP BY | | 11 | 77 | 4 (25)| 00:00:01 |
| 6 | COUNT | | | | | |
|* 7 | FILTER | | | | | |
| 8 | TABLE ACCESS FULL | EMPLOYEES | 107 | 749 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("E1"."DEPARTMENT_ID"="V"."DEPARTMENT_ID")
filter("E1"."SALARY">"V"."AVG_SALARY")
3 - access("E1"."DEPARTMENT_ID"=60)
4 - filter("V"."DEPARTMENT_ID"=60)
7 - filter(ROWNUM>1)
比較上面的兩個(gè)查詢可以看到，在第一個(gè)查詢中，DEPARTMENT_ID=60謂詞被推進(jìn)到視圖v中執(zhí)行了，這樣就使得內(nèi)部視圖查詢只需要獲得部門號(hào)為60的平均薪水就可以了；而在第二個(gè)查詢中則需要計(jì)算每個(gè)部門的平均薪水，然后在與外部查詢聯(lián)結(jié)的時(shí)候使用DEPARTMENT_ID=60條件過(guò)濾，相對(duì)而言這里為了等待應(yīng)用謂詞條件，查詢做了更多的工作。
四、使用物化視圖進(jìn)行查詢重寫
當(dāng)為物化視圖開啟查詢重寫功能時(shí)，CBO優(yōu)化器會(huì)評(píng)估相應(yīng)查詢對(duì)基表與物化視圖的訪問成本，如果優(yōu)化器認(rèn)為該查詢結(jié)果從物化視圖中獲得會(huì)更高效，那么就會(huì)其自動(dòng)選擇為物化視圖來(lái)執(zhí)行，否則則對(duì)基表生成查詢計(jì)劃。
還是來(lái)看栗子：
復(fù)制代碼 代碼如下:
SQL> set autotrace traceonly explain
SQL> select DEPARTMENT_ID,count(EMPLOYEE_ID) from EMPLOYEES group by DEPARTMENT_ID;
Execution Plan
----------------------------------------------------------
Plan hash value: 1192169904
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 11 | 33 | 4 (25)| 00:00:01 |
| 1 | HASH GROUP BY | | 11 | 33 | 4 (25)| 00:00:01 |
| 2 | TABLE ACCESS FULL| EMPLOYEES | 107 | 321 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------------
-- 創(chuàng)建物化視圖日志
SQL> create materialized view log on EMPLOYEES with sequence,
2 rowid (EMPLOYEE_ID,DEPARTMENT_ID) including new values;
Materialized view log created.
-- 創(chuàng)建物化視圖，并指定查詢重寫功能
SQL> create materialized view mv_t
2 build immediate refresh fast on commit
3 enable query rewrite as
4 select DEPARTMENT_ID,count(EMPLOYEE_ID) from EMPLOYEES group by DEPARTMENT_ID;
Materialized view created.
SQL> select DEPARTMENT_ID,count(EMPLOYEE_ID) from EMPLOYEES group by DEPARTMENT_ID;
Execution Plan
----------------------------------------------------------
Plan hash value: 1712400360
-------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 12 | 312 | 3 (0)| 00:00:01 |
| 1 | MAT_VIEW REWRITE ACCESS FULL| MV_T | 12 | 312 | 3 (0)| 00:00:01 |
-------------------------------------------------------------------------------------
Note
-----
- dynamic sampling used for this statement (level=2)
可以看到在第二個(gè)查詢中，雖然是指定的查詢EMPLOYEES表，但是優(yōu)化器自動(dòng)選擇了物化視圖的執(zhí)行路徑，因?yàn)樗袛喑鑫锘晥D已經(jīng)記載當(dāng)前查詢需要的結(jié)果集數(shù)據(jù)了，直接訪問物化視圖會(huì)獲得更高的效率。
值得注意的是，這里的物化視圖查詢重寫是自動(dòng)發(fā)生的，同樣也可以使用/*+ rewrite(mv_t) */提示的方式強(qiáng)制發(fā)生查詢重寫。
總結(jié)：
盡管優(yōu)化器在用戶透明的情況下改寫了我們的查詢結(jié)構(gòu)，不過(guò)通常情況下這都是基于CBO優(yōu)化模式下其判斷較為高效的選擇，這也是我們所期望的，同時(shí)為我們提供了一種學(xué)習(xí)方法，即在寫SQL語(yǔ)句的過(guò)程中時(shí)刻考慮優(yōu)化器的作用。
您可能感興趣的文章:- oracle分區(qū)表之hash分區(qū)表的使用及擴(kuò)展
- Oracle 12CR2查詢轉(zhuǎn)換教程之表擴(kuò)展詳解
