oracle研究中心：目前，CBO（Cost-Based Optimizer）是Oracle默認使用的查詢優化器Query Optimizer模式。在CBO中，SQL執行計劃的生成，是以一種尋找成本（Cost）最優爲目標導向的執行計劃探索過程。所謂成本（Cost）就是將CPU和IO消耗整合起來的量化指標，每一個執行計劃的成本就是經過優化器內部公式估算出的數字值。
與RBO（Rule-Based Optimizer）不同，CBO的靈活性建立在對數據統計量的強依賴關係上。CBO Query Optimizer工作的原料就是數據表、索引等對象統計量信息。在絕大部分情況下，CBO是可以幫助我們尋找到最優的執行計劃的。但是，在一些特殊的場合下，CBO在估算方面存在一些問題，可能導致一些問題。本篇主要介紹Oracle中多列統計量估算偏差問題。
1、環境準備
我們在Oracle 11g中進行試驗。
SQL> select * from v$version;
BANNER
----------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 – Production
創建數據表T，並且按照常規方法收集統計量信息。
SQL> create table t (id number, name varchar2(100));
Table created
SQL> select * from t;
ID NAME
---------- ----------
1 TT
2 MT
3 FT
1 MM
1 TT
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true);
PL/SQL procedure successfully completed
2、Multi-Columns估算偏差問題展現
此時，我們需要獲取到id=1並且name=’TT’的記錄。我們首先生成執行計劃。
SQL> explain plan for select * from t where id=1 and name='TT';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 6 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 1 | 6 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("NAME"='TT' AND "ID"=1)
13 rows selected
注意，從估算結果看，該SQL執行返回的Row Source數量爲1。也就是說，Oracle優化器認爲該SQL返回的結果數量爲1。但是實際上數量是多少呢？
--實際運行結果
SQL> select * from t where id=1 and name='TT';
ID NAME
---------- ----------
1 TT
1 TT
這就是出現了執行計劃與實際Row Source差異的現象。產生這種問題的原因，在於Oracle中默認只對單列進行統計量收集，而SQL中出現多列情況組合，就會發生問題。
具體來說，對數據表T，Oracle只會分別對列id和name進行統計量收集。在進行組合估算的時候，只會進行組合方式“剔除”結果集合。如果出現數據表T這種id=1和name=’TT’較多且符合的情況，估算出執行計劃的row source就會有偏差出現。
Row source在執行計劃成本公式中地位是很重要的，直接與進行邏輯物理讀（Logical/Physical Get）數據塊的個數相關，進而影響到Cost計算。如果發生Multi Columns估算問題，執行計劃成本估算的cost就會相對較小。
公允的說，在大多數情況下，由於Multi Column統計量引起的執行計劃錯誤問題是很少發生的。真正出現的場景是一些特殊的數據分佈結構和查詢方式上。如果深究這些問題，都能或多或少的存在數據庫設計不合理或者應用開發不適當的問題。
在過去的Oracle版本中，Multi Column問題是不能處理的。在Oracle 11g中，我們可以使用Oracle拓展統計量（也稱爲Column Group）來解決這個問題。
3、Multi-Column和Column Group
Oracle 11g對統計量提供了多列統計量的拓展功能。也就是說，我們可以指定對多列數據制定一個列組（Column Group），針對這個列組進行統計量收集過程。
在11g的dbms_stats包中，添加了函數create_extended_stats，用於收集拓展統計量。
function create_extended_stats(
ownname varchar2,
tabname varchar2,
extension varchar2)
return varchar2;
具體使用上，步驟如下：
根據create_extended_stats方法的提示，要求compatible參數選取在11以上。
SQL> show parameter compatible
NAME TYPE VALUE
------------------------------------ ----------- -------------
compatible string 11.2.0.0.0
創建id和name共同構成的column group。
SQL> var vc_res varchar2(100);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','T','(id,name)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STUIA0V924QODN5R5SCAKM60G#
調用方法後，反饋回一個內部的編號。之後，我們重新收集統計量信息。
--可以讓Oracle給Column Group收集直方圖信息；
SQL> exec dbms_stats.gather_table_stats(user,'T',cascade => true,method_opt => 'for columns (id,name) size skewonly');
PL/SQL procedure successfully completed
SQL> explain plan for select * from t where id=1 and name='TT';
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 12 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 2 | 12 | 2 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("NAME"='TT' AND "ID"=1)
13 rows selected
注意，此時Oracle執行計劃正確的獲得了結果集合row source信息。多列統計量生效。
那麼，Oracle在內部是怎麼進行組織和管理的呢？以及調用create_extend_stats方法獲得到那個隨機字符串是什麼含義呢？我們下面繼續進行探討。
4、Multi-Column本質論
在Oracle中，是怎麼組織多列組的信息呢？我們首先從列統計量入手分析。
SQL> select column_name, num_distinct,SAMPLE_SIZE, AVG_COL_LEN, HISTOGRAM from user_tab_col_statistics where table_name='T';
COLUMN_NAM NUM_DISTINCT SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
---------- ------------ ----------- ----------- ---------------
ID 3 5 3 FREQUENCY
NAME 4 5 3 FREQUENCY
SYS_STUIA0 4 5 12 FREQUENCY
V924QODN5R
5SCAKM60G#
在列中存在一個特殊列的統計信息，這裏的列名同我們生成拓展統計量時候的那個字符串。
SQL> var vc_res varchar2(100);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','T','(id,name)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STUIA0V924QODN5R5SCAKM60G#
同時，Oracle也提供了一個視圖user_stat_extensions來查看生成的拓展統計量。
SQL> select * from user_stat_extensions where extension_name = 'SYS_STUIA0V924QODN5R5SCAKM60G#';
TABLE_NAME EXTENSION_NAME EXTENSION CREATOR DROPPABLE
---------- ------------------------------ -------------------- ------- ---------
T SYS_STUIA0V924QODN5R5SCAKM60G# ("ID","NAME") USER YES
那麼，Oracle是不是同函數索引採用相同的內部策略，構建一個虛擬列進行管理呢？我們只有去到col$基表中進行檢查。
SQL> select object_id from dba_objects where object_name='T' and wner='SCOTT';
OBJECT_ID
----------
75482
SQL> select col#, name,DEFAULT$ from col$ where obj#=75482;
COL# NAME DEFAULT$
---------- ---------- ------------------------------
1 ID
2 NAME
0 SYS_STUIA0 SYS_OP_COMBINED_HASH("ID","NAM
V924QODN5R E")
5SCAKM60G#
果然，此處顯示的內容是：Oracle使用類似虛擬列的方法，構建了一個列。之後對這個列進行統計量收集。
5、Column Group的失效場景
在筆者的實驗中，發現並不是建立了column group之後，所有的統計量估算都是正確的。起碼當條件中存在非等號之後，拓展統計量估值是可能錯誤的。
SQL> exec dbms_stats.gather_table_stats(user,'EMP',cascade => true);
PL/SQL procedure successfully completed
--結果集合爲3
SQL> select * from emp where job='MANAGER' and sal>2000;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO
----- ---------- --------- ----- ----------- --------- --------- ------
7566 JONES MANAGER 7839 1981-4-2 2975.00 20
7698 BLAKE MANAGER 7839 1981-5-1 2850.00 30
7782 CLARK MANAGER 7839 1981-6-9 2450.00 10
查看執行計劃中的估算值。
SQL> explain plan for select * from emp where job='MANAGER' and sal>2000;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 38 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1 | 38 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("JOB"='MANAGER' AND "SAL">2000)
13 rows selected
此時，我們收集一下拓展統計量。
SQL> var vc_res varchar2(1000);
SQL> exec :vc_res := dbms_stats.create_extended_stats('SCOTT','EMP','(job,sal)');
PL/SQL procedure successfully completed
vc_res
---------
SYS_STU73TUM4UV1A$7U9OVY05$MH6
SQL> select * from user_stat_extensions;
TABLE_NAME EXTENSION_NAME EXTENSION CREATOR DROPPABLE
---------- ------------------------------ -------------------- ------- ---------
EMP SYS_STU73TUM4UV1A$7U9OVY05$MH6 ("JOB","SAL") USER YES
SQL> exec dbms_stats.gather_table_stats(user,'EMP',method_opt => 'for columns (job,sal) size skewonly');
PL/SQL procedure successfully completed
SQL> select column_name, num_distinct,SAMPLE_SIZE, AVG_COL_LEN, HISTOGRAM from user_tab_col_statistics where table_name='EMP';
COLUMN_NAM NUM_DISTINCT SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
---------- ------------ ----------- ----------- ---------------
（篇幅原因，有省略。。。。。。）
DEPTNO 3 14 3 FREQUENCY
SYS_STU73T 12 14 12 FREQUENCY
UM4UV1A$7U
9OVY05$MH6
此時，執行計劃並沒有改變。
SQL> explain plan for select * from emp where job='MANAGER' and sal>2000;
Explained
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 3956160932
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 38 | 3 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| EMP | 1 | 38 | 3 (0)| 00:00:01 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("JOB"='MANAGER' AND "SAL">2000)
13 rows selected
這說明拓展統計量在非等號情況下，是存在一些問題的。
6、其他注意問題和結論
此外，在使用column group上，我們還需要注意下面的問題：
ü 拓展列中不允許出現虛擬列（Virtual Column）；
ü 不能對sys schema下的數據表列建立column group；
ü 不能對聚簇表（Cluster Table）、索引組織表（Index Organized Table）、臨時表（Temporary Table）和外部表（External Table）上的列創建Column Group；
ü 一個數據表中創建的拓展列數目不能超過20和數據表10%非虛擬列的數目；
ü 一個拓展列組中包括了列數目位於2-32的範圍內；
ü 一個列只能出現在一個拓展列組中；
ü 列組中不能包括表達式；
ü compatible參數必須在11.0.0.0以上；
最後，個人感覺在實際中，特別是開發環境下很少會使用到column group的功能。因爲解決執行計劃問題的手段很多，column group不是最優的方法。而在運維環境中，常常會遇到書寫很糟糕的SQL和設計。此時運維人員通常沒有機會修改SQL源代碼。所以，column group作爲一種運維手段，是可以進行嘗試的。
--------------------------------------ORACLE-DBA----------------------------------------
最權威、專業的Oracle案例資源彙總之【學習筆記】oracle11g multi column statistics深入研究筆記
原文唯一網址：http://www.oracleplus.net/arch/1464.html