按圖索驥：SQL中資料傾斜問題的處理思路與方法

阿新 • • 發佈：2022-05-03

資料傾斜即表中某個欄位的值分佈不均勻，比如有100萬條記錄，其中欄位A中有90萬都是相同的值。這種情況下，欄位A作為過濾條件時，可能會引起一些效能問題。

本文通過示例分享部分場景的處理方法

未使用繫結變數
使用繫結變數
幾種特殊場景

測試環境說明

資料庫版本：ORACLE 11.2.0.4

新建測試表tb_test：

create tablescott.tb_test as select * from dba_objects;

建立索引：

create indexscott.idx_tb_test_01 on scott.tb_test(object_id);

更新資料,使用資料分佈不均勻：

update scott.tb_testset object_id=10 where object_id>10;

commit;

檢視資料分佈情況：

select object_id,count(1) from scott.tb_test groupby object_id;

未使用繫結變數

未使用繫結變數的情況下通常資料分佈不均勻不會造成問題，但這主要依賴於三個方面：

資料分佈不均勻的欄位是否做為過濾條件或連線條件。
資料分佈不均勻的欄位是否有收集直方圖，如果沒有收集直方圖就可能會有問題。在沒有收集直方圖的情況下，這個欄位的過濾性DENSITY都是等於1/NUM_DISTINCT;在收集了直方圖的情況下，這個欄位的過濾性會根據條件值在直方圖中的分佈比例來計算。

資料庫cursor_sharing引數的值是否為exact，如果引數的值為force，相當於使用繫結變數。那就會存在類似使用繫結變數時存在的問題，下節會講到。

未收集直方圖的情況：

對測試表tb_test進行統計資訊收集，收集時指定不收集欄位object_id的直方圖：

begin

dbms_stats.gather_table_stats('scott','TB_TEST', method_opt => 'forcolumns object_id size 1',cascade=>true);

end;

確認是否收集了直方圖：

selecttable_name,column_name,histogram from dba_tab_col_statistics

wheretable_name='TB_TEST' and column_name='OBJECT_ID';

從上圖可以看出欄位OBJECT_ID未收集直方圖。

執行測試SQL:

返回記錄比較少的值：

select * fromscott.TB_TEST where object_id=1;

返回記錄比較多的值：

select * fromscott.TB_TEST where object_id=10;

檢視SQL資訊：

selectsql_text,sql_id,plan_hash_value from v$sql

where sql_text like'select * from scott.TB_TEST where object_id=%';

從上圖可以看出，兩條SQL的PLAN_HASH_VALUE是一樣的，也就是走了相同的執行計劃。

再看一下這兩條SQL的執行計劃：

SELECT SQL_ID,
       PLAN_HASH_VALUE,
       LPAD(' ', 4 * DEPTH) || OPERATION ||OPTIONS OPERATION,
       OBJECT_NAME,
       CARDINALITY,
       BYTES,
       COST,
       TIME
  FROM V$SQL_PLAN
 WHERE sql_id in('8zqcak67wwh8f','bfag4mr23qht5')
 ORDER BY ADDRESS, ID

從上面也可以看出兩條SQL的執行計劃是相同的。

收集直方圖的情況：

下面收集欄位OBJECT_ID的直方圖：

begin

dbms_stats.gather_table_stats('scott','TB_TEST', method_opt => 'forcolumns object_id size auto',cascade=>true);

end;

確認是否收集了直方圖：

selecttable_name,column_name,histogram from dba_tab_col_statistics

wheretable_name='TB_TEST' and column_name='OBJECT_ID';

select * fromdba_tab_histograms

wheretable_name='TB_TEST' and column_name='OBJECT_ID';

從上圖可以看出欄位OBJECT_ID有收集直方圖。

重新執行SQL：

返回記錄比較少的值：

select * from scott.TB_TEST where object_id=1;

返回記錄比較多的值：

select * fromscott.TB_TEST where object_id=10;

檢視SQL資訊：

selectsql_text,sql_id,plan_hash_value,address,hash_value from v$sql

where sql_text like'select * from scott.TB_TEST where object_id=%';

從上面可以看出，兩條SQL依然使用之前相同的執行計劃，執行計劃並沒有根據資料分佈發生改變。

這是因為我們在收集統計資訊時，未指定引數no_invalidate => false，原本這兩條SQL的CURSOR未失效，沒有進行重新解析。

我們通過以下儲存過程將這兩個CURSOR清除，這樣再執行就會重新解析了。

BEGIN

DBMS_SHARED_POOL.PURGE('00000000B34598F8,2412658958', 'C');

DBMS_SHARED_POOL.PURGE('00000000B37AEDE8,3292218149', 'C');

END;

確認是否已清除：

selectsql_text,sql_id,plan_hash_value,address,hash_value from v$sql

where sql_text like 'select *from scott.TB_TEST where object_id=%';

從上面可以看出查詢無結果，說明已經清除。

讓已存在的CURSOR失效的方法：

1、在收集統計時，加no_invalidate => false引數：

begin

dbms_stats.gather_table_stats('scott','TB_TEST', method_opt => 'forcolumns object_id size auto',cascade=>true,no_invalidate =>false );

end;

2、整個重新整理share pool

alter system flushshared_pool;

3、對這個表做ddl操作或授權都可以。

但以上說的這些方法，因為影響範圍的不同，風險也不同。

相對來講，DBMS_SHARED_POOL.PURGE影響是最小的，只對指定的CURSOR做清除。由於我是在個人的測試環境上演示，後面我為了方便操作，直接alter system flush shared_pool。

上面通過DBMS_SHARED_POOL.PURGE將兩個CURSOR清除後，再次執行SQL:

返回記錄比較少的值：

select * fromscott.TB_TEST where object_id=1;

返回記錄比較多的值：

select * fromscott.TB_TEST where object_id=10;

檢視SQL資訊：

selectsql_text,sql_id,plan_hash_value from v$sql

where sql_text like'select * from scott.TB_TEST where object_id=%';

從上圖的PLAN_HASH_VALUE可以看出，兩條SQL使用了不同的執行計劃。

對於資料分佈不均勻是否可使用非繫結變數來解決，主要注意兩個方面，SQL執行的頻率，資料分佈不均勻欄位上的NUM_DISTINCT值的數量。注意這兩個方面根本上都是為了防止使用非繫結變數引起的硬解析問題。

使用繫結變數

以下討論的前提是已經對欄位object_id收集過直方圖的情況。

執行下面兩個pl/sql,兩個繫結變數的資料分佈不同：

返回記錄比較少的值：

DECLARE
  V_SQL VARCHAR2(3000);
BEGIN
  V_SQL := 'select * from scott.tb_test whereobject_id=:1';
  EXECUTE IMMEDIATE V_SQL
    USING 1;
END;
返回記錄比較多的值：
DECLARE
  V_SQLVARCHAR2(3000);
BEGIN
  V_SQL := 'select* from scott.tb_test where object_id=:1';
  EXECUTE IMMEDIATEV_SQL
    USING 10;
END;

從下面的查詢結果可以看出，兩個繫結變數的資料分佈不同，但SQL只生成了一個執行計劃：

select sql_id,plan_hash_value,a.sql_text from v$sql a

where sql_text like'select * from scott.tb_test where object_id=:1';

從上面可以看出雖然欄位OBJECT_ID上有使用直方圖，但因為使用了繫結變數，ORACLE只硬解析了一次。Oracle 9i就開始引入的BIND PEEK不能解決這個問題，因為BIND PEEK只是發生在第一次硬解析。

解決方法：

方法1：通過在應用程式碼中判斷

為了避免非繫結變數的解析問題，並且可以在邏輯上將傾斜的值區分出來，則可以在應用程式碼中根據值的不同讓其它走不同的執行計劃。

虛擬碼：

if variable =10then

execute‘select /*+full(TB_TEST)*/ * from scott.TB_TEST where object_id=:1’using variable;

else

execute‘select /*+index(TB_TEST IDX_TB_TEST_01)*/* from scott.TB_TEST whereobject_id=:1’using variable;

…

end if;

方法2：通過HINT:bindaware

上面剛才講到Oracle 9i就開始引入的BIND PEEK不能解決這個問題，因為只會在第一次硬解析的時候去窺視繫結變數的值。從ORACLE11G開始引入了ACS的特性，即AdaptiveCursor Sharing自適應遊標，它可以共享監視候選查詢的執行統計資訊，並使相同的查詢能夠生成和使用不同的繫結值集合的不同執行計劃。例如，優化器可能會選擇繫結值1的一個執行計劃和繫結值10的一個執行計劃。

自適應遊標的主要依賴於bind_sensitive遊標的繫結敏感性和bind_aware遊標的繫結感知性。大概的作用就是在資料庫第一次執行一條SQL語句時，做一次硬解析，優化器發現使用繫結變數並在過濾條件上有直方圖，它將儲存遊標的執行統計資訊。在下一次使用不同繫結值執行相同SQL進行軟解析時，把執行統計資訊和儲存在遊標中的執行統計資訊進行比較，來決定是否產生新的執行計劃。這些執行統計資訊可以在V$SQL_CS_*相關的檢視檢視。

V$SQL_CS_HISTOGRAM：在執行歷史直方圖上顯示執行統計的分佈。 V$SQL_CS_SELECTIVITY：對帶繫結變數的過濾條件顯示儲存在遊標中的選擇性區域或範圍。 V$SQL_CS_STATISTICS：包含資料庫收集的執行資訊，用來確定是否應該使用BIND_AWARE的遊標共享。

另外在V$SQL中增加了IS_BIND_SENSITIVE和IS_BIND_AWARE列，來標識一個遊標是否為繫結敏感和是否感知遊標共享。

自適應遊標的概念文件可參考：Adaptive Cursor Sharing: Overview(Doc ID 740052.1)。

預設自適應遊標特性是開啟的，預設引數為：

--_optim_peek_user_binds=TRUE

_optimizer_adaptive_cursor_sharing=TRUE

_optimizer_extended_cursor_sharing=UDO

_optimizer_extended_cursor_sharing_rel=SIMPLE

但根據我們的最佳實踐是不建議開啟的，防止大量SQL執行計劃的可變性引起的不穩定和新特性帶來的Bug，但我們可以針對指定的SQL語句使用。

下面演示通過SQL_PATCH對SQL加BIND_AWARE的HINT,解決資料傾斜的問題。

同樣是上面測試的SQL，我們對SQL增加BIND_AWARE的HINT：

DECLARE

V_SQL CLOB;

begin

--取出原SQL的文字

SELECTSQL_FULLTEXT INTO V_SQL FROM V$SQL WHERE SQL_ID = 'fgagrcttxvq2a' AND ROWNUM =1;

--增加HINT

sys.dbms_sqldiag_internal.i_create_patch(sql_text => V_SQL,

hint_text => 'BIND_AWARE',

name => 'sql_fgagrcttxvq2a');

end;

執行成功後，可在dba_sql_patches檢視中檢視相關資訊

select * from dba_sql_patches

where name='sql_fgagrcttxvq2a';

順便說一下，下面是dbms_sqldiag_internal.i_create_patch的儲存過程，可以看出它其實也是呼叫了I_CREATE_SQL_PROFILE這個過程，和使用SQL_PROFILE在底層是一樣的。只是當前的場景使用sql_patch要比使用SQL_PROFILE要方便。

PACKAGE dbms_sqldiag_internal
 PROCEDURE I_CREATE_PATCH(
          SQL_TEXT      IN CLOB,
          HINT_TEXT     IN VARCHAR2,
          NAME          IN VARCHAR2 := NULL,
          DESCRIPTION   IN VARCHAR2 := NULL,
          CATEGORY      IN VARCHAR2 :='DEFAULT',
                   VALIDATE      IN BOOLEAN  := TRUE)
  IS
   RET_NAME  VARCHAR2(30);
   HS        SYS.SQLPROF_ATTR;
  BEGIN
   COMMIT;
   DBMS_SMB.CHECK_SMB_PRIV;
    HS:= SYS.SQLPROF_ATTR(HINT_TEXT);
   RET_NAME := DBMS_SQLTUNE_INTERNAL.I_CREATE_SQL_PROFILE(
     SQL_TEXT => SQL_TEXT,
      PROFILE_XML =>DBMS_SMB_INTERNAL.VARR_TO_HINTS_XML(HS),
     NAME => NAME,
     DESCRIPTION => DESCRIPTION,
     CATEGORY => CATEGORY,
     CREATOR => SYS_CONTEXT('USERENV', 'SESSION_USER'),
     VALIDATE => VALIDATE,
     TYPE => 'PATCH',
     IS_PATCH => TRUE);
  END;

清空共享池:

alter system flush shared_pool;

下面看一下使用BIND_AWARE這個HINT後的效果：執行下面兩個pl/sql,兩個繫結變數的資料分佈不同

返回記錄比較少的值：

DECLARE
  V_SQLVARCHAR2(3000);
BEGIN
  V_SQL := 'select* from scott.tb_test where object_id=:1';
  EXECUTE IMMEDIATEV_SQL
    USING 1;
END;

返回記錄比較多的值：

DECLARE
  V_SQLVARCHAR2(3000);
BEGIN
  V_SQL := 'select* from scott.tb_test where object_id=:1';
  EXECUTE IMMEDIATEV_SQL
    USING 10;
END;

檢視SQL資訊：

select sql_id,plan_hash_value,a.sql_text,is_bind_sensitive,is_bind_aware,is_shareable,sql_patchfrom v$sql a

where sql_text like 'select * from scott.tb_test whereobject_id=:1';

從上面可以看出，ORACLE根據資料分佈選擇了不同的執行計劃，並且都有使用到這個SQL_PATCH。

檢視ACS(adaptive cursor sharing)和bind peek相關引數：

select name,value
  from (selectnam.ksppinm name,
              val.KSPPSTVL value,
              --nam.ksppdesc description,
              val.ksppstdf isdefault
          fromsys.x$ksppi nam, sys.x$ksppcv val
         wherenam.inst_id = val.inst_id
           andnam.indx = val.indx)
 where name in('_optimizer_adaptive_cursor_sharing',
               '_optimizer_extended_cursor_sharing_rel',
               '_optimizer_extended_cursor_sharing',
               '_optim_peek_user_binds')

從上面可以看出ACS是關閉的，說明這種方法在ACS關閉的情況下也是可以生效的。

上面的測試中，_optim_peek_user_binds=TRUE，如果_optim_peek_user_binds=FALSE，將dbms_sqldiag_internal.i_create_patch中的hint_text值改為'OPT_PARAM(''_optim_peek_user_binds'' ''true'') BIND_AWARE'即可。

如果不再需要SQLPATCH，可通過dbms_sqldiag.drop_sql_patch刪除。

方法3：通過SPM

通過DBMS_SPM.evolve_sql_plan_baseline演化基線的方式。此方法不再演示，可參考文件：How to Evolve a SQL Plan Baseline and Adjust the AcceptanceThreshold (Doc ID 1617790.1)。

其它特殊情況

單欄位分佈不均勻，多欄位分佈均勻

舉個簡單的例子：

select * from tb where a=:1 and b=:2

欄位a和欄位b都是資料分佈不均勻的欄位，但業務邏輯上，在同一行記錄中，欄位a或者欄位b，會有一個是過濾性強的。之前使用者分別在欄位a和欄位b上建了兩個索引。這樣在繫結變數的情況下，就會出現這條SQL一直選擇其中一個索引做索引範圍掃描，當遇到傾斜的值時就會出現效能問題。最後通過將欄位a和欄位b建複合索引解決了此問題，當建立複合索引後，欄位a或欄位b其中一個值是傾斜時不會影響索引掃描的效能。

Null分佈問題

舉個簡單的例子：

select * from tb where a isnull;

表tb中大部分記錄中欄位a的值都為非空，經常要查詢欄位a為空的記錄。單獨在欄位a上建索引，由於此索引中不存null值，所以where條件a is null無法走索引。可通過建(a,1)的複合索引將欄位a的NULL值也存進去，使a is null使用索引。

！=分佈問題

舉個簡單的例子：

select * from tb where a !=1;

表tb中大部分記錄中欄位a的值都為1，經常要查詢欄位a!=1的記錄，欄位a為not null。單獨在欄位a上建索引，通常這樣的SQL是會走全表掃描，如果強制走索引會走index full scan效率也不高。對於這種情況，如果想提高此SQL的效能，當欄位a中!=1的值種類固定且不多時，可以將where條件a！=1改寫為a in (x,y,z) 的形式--X/Y/Z為！=1的值;當欄位a中!=1的值種類不固定，可以建函式索引decode(a,1,null,'2')，並將where條件a!=1改寫為decode(a,1,null,'2')='2'，使其走索引範圍掃描，提高SQL效能。

按圖索驥：SQL中資料傾斜問題的處理思路與方法

收集直方圖的情況：

方法1：通過在應用程式碼中判斷

方法2：通過HINT:bindaware

方法3：通過SPM

單欄位分佈不均勻，多欄位分佈均勻

Null分佈問題

！=分佈問題

按圖索驥：SQL中資料傾斜問題的處理思路與方法

關於Ajax接收後臺返回的 Long型別資料的處理思路

Hive sql 常見資料傾斜(型別不匹配、複雜join條件)的分析解決

Python Numpy中資料的常用儲存與讀取方法

python 實現資料庫中資料新增、查詢與更新

python 實現資料庫中資料新增、查詢與更新的示例程式碼

PyTorch教程-3：PyTorch中神經網路的構建與訓練基礎

小專案中管理npm包版本的思路與方法

sql中的truncate、 delete 與drop的區別

JS中資料型別的正確判斷方法例項

vue中資料請求的三種方法

對比SQL中簡單巢狀查詢與非巢狀查詢的異同

Python學習（四）：基本的資料結構——字典及常用方法

JavaScript 語法：陣列的定義及其常用屬性與方法

DNS異常分析思路與方法

2021-11-24 隱寫術破解思路與方法

天池nlp新人賽_task2：資料預處理改進和一些思路

sql中的開窗函式：複雜查詢需求的簡單處理

python插入到sql中的資料包含單引號（‘）的處理方法

批處理指令碼：打包制定資料夾中的所有子資料夾

按圖索驥：SQL中資料傾斜問題的處理思路與方法

收集直方圖的情況：

方法1：通過在應用程式碼中判斷

方法2：通過HINT:bindaware

方法3：通過SPM

單欄位分佈不均勻，多欄位分佈均勻

Null分佈問題

！=分佈問題

相關推薦