2. 程式人生 > >資料倉庫設計的隱患-標量子查詢

資料倉庫設計的隱患-標量子查詢

阿新 • • 發佈：2019-02-06

首先，來理解一下標量子查詢：處於select之後from之前的子查詢稱為標量子查詢 .比如：select  num1,cal,(select name from t2 where t2.id = t1.id)from t1；舉這個例子只是為了方便理解標量的含義。當然定義為返回單列的選擇語句，或者返回一行的表示式的子查詢稱為標量子查詢。

標量子查詢的缺點十分明顯：驅動表固定是外表t1, t1返回的結果集傳值t2得到結果。所以如果t1表過大（或者以後t1表逐漸增長以後會變得很大）。將會引起很大的效能問題【資料倉庫跑批流程應該禁用標量子查詢】

今天這條SQL運行了5個小時沒出結果。。。。。。。(不得不說耐心真好，我一般最多等十分鐘)

SELECT /*+ NO_USE_HASH(C,B)*/
 C.CUST_ACCT_NO,
 C.PRIM_ACCT,
 ACCOUNT_SYSTEM,
 CUSTOMER_TYPE,
 CUSTOMER_STATUS,
 CREATE_DT,
 HOME_BRANCH_NO,
 COMPANY_SIZE,
 NOTICE_IND,
 NOTICE_CUST_NO,
 STMT_FREQUENCY,
 STMT_CYCLE,
 STMT_DAY,
 ID_NO,
 ID_TYPE,
 SHORT_NAME,
 EMAIL_ADD1,
 EMAIL_ADD2,
 CREDIT_RANKING,
 TITLE_CODE,
 NAME1,
 ADD1,
 POSTCODE,
 PHONE_NO_RES,
 PHONE_RES_EXT,
 PHONE_NO_BUS,
 PHONE_BUS_EXT,
 FAX_NO,
 TELEX_NO,
 PCODE_RGSTER,
 REGSTR_ADD1,
 REGSTR_ADD2,
 PHONE_RGSTR_NO,
 PHONE_RGSTR_EXT,
 BIRTH_DATE_1,
 SEX_CODE,
 EMPLOYER_NAME,
 EMPLOYED_FROM,
 EMPLOYER_ADDR,
 OCCUP_DESCRIP,
 OCCUPATION_CODE,
 INCOME,
 INCOME_WMY,
 COMPANY_NO,
 BUSINESS_NO,
 LICENCE_NO,
 BOSS_NAME,
 BOSS_BDAY,
 BUS_RGSTR_DATE,
 CAPITAL_AMT,
 CONTACT_REL_1,
 PHONE_NO_1,
 ADD2,
 ADD3,
 ADD4,
 MOBILE_NO,
 FXSP_TYPE,
 INDUSTRY_CODE,
 BUS_SECTOR_CODE,
 CUST_SUB_TYPE,
 DEP_STMT_TYPE,
 ID_ISSUE_DATE,
 ID_EXP_DATE,
 REGISTRY_ADD,
 ID_ISSUE_PLAC,
 LST_MNT_DATE,
 B.BRANCH_NO
  FROM CUSM_T C
 INNER JOIN (SELECT
             DISTINCT CUSTOMER_NO,
                      (SELECT SJJGM
                         FROM JGDY H
                        WHERE H.JGM = CB_ACCT.BRANCH_NO) BRANCH_NO
               FROM CB_ACCT) B ON C.CUST_ACCT_NO = B.CUSTOMER_NO;
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

 
Plan hash value: 2079508004
 
---------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |           |    18M|    14G|       |  1793K  (1)| 00:04:41 |
|*  1 |  INDEX SKIP SCAN              | JGDY_IDX3 |     1 |     8 |       |     1   (0)| 00:00:01 |
|   2 |  MERGE JOIN                   |           |    18M|    14G|       |  1793K  (1)| 00:04:41 |
|   3 |   SORT JOIN                   |           |    18M|   397M|       |   147K  (1)| 00:00:24 |
|   4 |    VIEW                       |           |    18M|   397M|       |   147K  (1)| 00:00:24 |
|   5 |     HASH UNIQUE               |           |    18M|   380M|  1107M|   147K  (1)| 00:00:24 |
|   6 |      TABLE ACCESS STORAGE FULL| CB_ACCT2  |    36M|   760M|       | 71431   (1)| 00:00:12 |
|*  7 |   SORT JOIN                   |           |    19M|    14G|    35G|  1645K  (1)| 00:04:18 |
|   8 |    TABLE ACCESS STORAGE FULL  | CUSM_T    |    19M|    14G|       |   306K  (1)| 00:00:48 |
---------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - access("H"."JGM"=:B1)
       filter("H"."JGM"=:B1)
   7 - access("C"."CUST_ACCT_NO"="B"."CUSTOMER_NO")
       filter("C"."CUST_ACCT_NO"="B"."CUSTOMER_NO")
通過SQL和PLAN都可以很容易的找出標量子查詢

1.select之後from之前，當然這個SQL的標量隱藏在了內聯視圖裡面了

(SELECT
             DISTINCT CUSTOMER_NO,
                      (SELECT SJJGM
                         FROM JGDY H
                        WHERE H.JGM = CB_ACCT.BRANCH_NO) BRANCH_NO
               FROM CB_ACCT) B

2.PLAN的id=1和2那兩步,縮排一樣,而且沒有連線方式的父親節點

|*  1 |  INDEX SKIP SCAN              | JGDY_IDX3 |     1 |     8 |       |     1   (0)| 00:00:01 |
|   2 |  MERGE JOIN                   |           |    18M|    14G|       |  1793K  (1)| 00:04:41 |

通過這兩點均可以判斷SQL裡面包含標量.如果SQL特別長就直接看PLAN就行了

標量是否產生效能問題，注意取決於主表(外表)返回的行數.其實我們都知道這種資料倉庫跑批的表不可能小。象徵性的查一下


我之前的部落格裡面發過這個指令碼 http://blog.csdn.net/skybig1988/article/details/71125223 也可以自己定製，很簡單

可以看出表的行數很大，不適合走標量(>10000行)

對於標量子查詢,只能通過改寫【標量子查詢可以等價改寫為外連線】

當然此處的標量改寫十分簡單.有些複雜的比如 聚合類、不等值、樹形查詢的標量千萬需要注意改寫前後是否等價

SELECT /*+ NO_USE_HASH(C,B)*/
 C.CUST_ACCT_NO,
 C.PRIM_ACCT,
 ACCOUNT_SYSTEM,
 CUSTOMER_TYPE,
 CUSTOMER_STATUS,
 CREATE_DT,
 HOME_BRANCH_NO,
 COMPANY_SIZE,
 NOTICE_IND,
 NOTICE_CUST_NO,
 STMT_FREQUENCY,
 STMT_CYCLE,
 STMT_DAY,
 ID_NO,
 ID_TYPE,
 SHORT_NAME,
 EMAIL_ADD1,
 EMAIL_ADD2,
 CREDIT_RANKING,
 TITLE_CODE,
 NAME1,
 ADD1,
 POSTCODE,
 PHONE_NO_RES,
 PHONE_RES_EXT,
 PHONE_NO_BUS,
 PHONE_BUS_EXT,
 FAX_NO,
 TELEX_NO,
 PCODE_RGSTER,
 REGSTR_ADD1,
 REGSTR_ADD2,
 PHONE_RGSTR_NO,
 PHONE_RGSTR_EXT,
 BIRTH_DATE_1,
 SEX_CODE,
 EMPLOYER_NAME,
 EMPLOYED_FROM,
 EMPLOYER_ADDR,
 OCCUP_DESCRIP,
 OCCUPATION_CODE,
 INCOME,
 INCOME_WMY,
 COMPANY_NO,
 BUSINESS_NO,
 LICENCE_NO,
 BOSS_NAME,
 BOSS_BDAY,
 BUS_RGSTR_DATE,
 CAPITAL_AMT,
 CONTACT_REL_1,
 PHONE_NO_1,
 ADD2,
 ADD3,
 ADD4,
 MOBILE_NO,
 FXSP_TYPE,
 INDUSTRY_CODE,
 BUS_SECTOR_CODE,
 CUST_SUB_TYPE,
 DEP_STMT_TYPE,
 ID_ISSUE_DATE,
 ID_EXP_DATE,
 REGISTRY_ADD,
 ID_ISSUE_PLAC,
 LST_MNT_DATE,
 B.BRANCH_NO
  FROM CUSM_T C
 INNER JOIN (SELECT DISTINCT CUSTOMER_NO,
                      sjjgm BRANCH_NO
               FROM CB_ACCT  LEFT JOIN jgdy  ON  cb_acct.branch_no=jgm
               ) B ON C.CUST_ACCT_NO = B.CUSTOMER_NO;
Plan hash value: 2285049241
 
----------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |           |    36M|    28G|       |  1834K  (1)| 00:04:47 |
|   1 |  MERGE JOIN                    |           |    36M|    28G|       |  1834K  (1)| 00:04:47 |
|   2 |   SORT JOIN                    |           |    36M|   829M|       |   188K  (1)| 00:00:30 |
|   3 |    VIEW                        |           |    36M|   829M|       |   188K  (1)| 00:00:30 |
|   4 |     HASH UNIQUE                |           |    36M|  1037M|  1384M|   188K  (1)| 00:00:30 |
|*  5 |      HASH JOIN RIGHT OUTER     |           |    36M|  1037M|       | 71501   (1)| 00:00:12 |
|   6 |       INDEX FULL SCAN          | JGDY_IDX3 |  1241 |  9928 |       |     1   (0)| 00:00:01 |
|   7 |       TABLE ACCESS STORAGE FULL| CB_ACCT2  |    36M|   760M|       | 71431   (1)| 00:00:12 |
|*  8 |   SORT JOIN                    |           |    19M|    14G|    35G|  1645K  (1)| 00:04:18 |
|   9 |    TABLE ACCESS STORAGE FULL   | CUSM_T    |    19M|    14G|       |   306K  (1)| 00:00:48 |
----------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   5 - access("CB_ACCT"."BRANCH_NO"="JGM"(+))
   8 - access("C"."CUST_ACCT_NO"="B"."CUSTOMER_NO")
       filter("C"."CUST_ACCT_NO"="B"."CUSTOMER_NO")
改寫之後標量消失.SQL運行了7分鐘出結果。但是這個SQL裡面沒有不等值連線，走MERGE JOIN顯然毫無意義。明顯走HASH是最好的選擇

一直不理解SQL上面的/*+ NO_USE_HASH(C,B)*/ 的意義，最後開發迴應說這個 HINT是為了讓SQL走巢狀迴圈，因為走NL比較快。聽到這個理由我也是呵呵了！

這裡我簡單的說一下NL、HASH、SMJ在實際工作中該如何選擇：

巢狀迴圈：
     看SQL語句的返回條數 太大的話一般都是錯誤的
     看驅動表返回的行數   一般不能超過1w   最好在1k 以內（但是這個取決於伺服器效能，可能效能好的伺服器臨界值超過20w都可行）
     看被驅動表的連結列 是否包含在索引裡面     （必須包含在索引裡面）
     看到distinct ,group by ,sum()一般不走巢狀迴圈（資料量超級多才去group by）當然資料量少的話也可以走NL

雜湊連線只能用於等值連線

排序合併連線唯一的作用：非等值連線

去掉/*+ NO_USE_HASH(C,B)*/ 之後.SQL運行了30秒便出結果

SELECT
 C.CUST_ACCT_NO,
 C.PRIM_ACCT,
 ACCOUNT_SYSTEM,
 CUSTOMER_TYPE,
 CUSTOMER_STATUS,
 CREATE_DT,
 HOME_BRANCH_NO,
 COMPANY_SIZE,
 NOTICE_IND,
 NOTICE_CUST_NO,
 STMT_FREQUENCY,
 STMT_CYCLE,
 STMT_DAY,
 ID_NO,
 ID_TYPE,
 SHORT_NAME,
 EMAIL_ADD1,
 EMAIL_ADD2,
 CREDIT_RANKING,
 TITLE_CODE,
 NAME1,
 ADD1,
 POSTCODE,
 PHONE_NO_RES,
 PHONE_RES_EXT,
 PHONE_NO_BUS,
 PHONE_BUS_EXT,
 FAX_NO,
 TELEX_NO,
 PCODE_RGSTER,
 REGSTR_ADD1,
 REGSTR_ADD2,
 PHONE_RGSTR_NO,
 PHONE_RGSTR_EXT,
 BIRTH_DATE_1,
 SEX_CODE,
 EMPLOYER_NAME,
 EMPLOYED_FROM,
 EMPLOYER_ADDR,
 OCCUP_DESCRIP,
 OCCUPATION_CODE,
 INCOME,
 INCOME_WMY,
 COMPANY_NO,
 BUSINESS_NO,
 LICENCE_NO,
 BOSS_NAME,
 BOSS_BDAY,
 BUS_RGSTR_DATE,
 CAPITAL_AMT,
 CONTACT_REL_1,
 PHONE_NO_1,
 ADD2,
 ADD3,
 ADD4,
 MOBILE_NO,
 FXSP_TYPE,
 INDUSTRY_CODE,
 BUS_SECTOR_CODE,
 CUST_SUB_TYPE,
 DEP_STMT_TYPE,
 ID_ISSUE_DATE,
 ID_EXP_DATE,
 REGISTRY_ADD,
 ID_ISSUE_PLAC,
 LST_MNT_DATE,
 B.BRANCH_NO
  FROM CUSM_T C
 INNER JOIN (SELECT DISTINCT CUSTOMER_NO,
                      sjjgm BRANCH_NO
               FROM CB_ACCT  LEFT JOIN jgdy  ON  cb_acct.branch_no=jgm
               ) B ON C.CUST_ACCT_NO = B.CUSTOMER_NO

Plan hash value: 967350049
 
---------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |           |    36M|    28G|       |  1059K  (1)| 00:02:46 |
|*  1 |  HASH JOIN                    |           |    36M|    28G|  1244M|  1059K  (1)| 00:02:46 |
|   2 |   VIEW                        |           |    36M|   829M|       |   188K  (1)| 00:00:30 |
|   3 |    HASH UNIQUE                |           |    36M|  1037M|  1384M|   188K  (1)| 00:00:30 |
|*  4 |     HASH JOIN RIGHT OUTER     |           |    36M|  1037M|       | 71501   (1)| 00:00:12 |
|   5 |      INDEX FULL SCAN          | JGDY_IDX3 |  1241 |  9928 |       |     1   (0)| 00:00:01 |
|   6 |      TABLE ACCESS STORAGE FULL| CB_ACCT2  |    36M|   760M|       | 71431   (1)| 00:00:12 |
|   7 |   TABLE ACCESS STORAGE FULL   | CUSM_T    |    19M|    14G|       |   306K  (1)| 00:00:48 |
---------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   1 - access("C"."CUST_ACCT_NO"="B"."CUSTOMER_NO")
   4 - access("CB_ACCT"."BRANCH_NO"="JGM"(+))
其實這個SQL還可以繼續優化，ID=5這一步INDEX FULL SCAN是單塊讀改成全表掃描可以提升100+倍，加上一體機本身的全表掃描優化TABLE ACCESS STORAGE FULL。提升會更多！！！

如上可知標量子查詢是一個非常恐怖的用法。當外部表返回的資料量不大時。完全不會引起效能問題。但是此時隱患已經埋下

隨著外部表資料量的增加。標量的效能會慢慢受到影響，一旦過了這個臨界值。效能下降的非常明顯和可怕。所以在資料倉庫

中應該用外連線代替標量，避免給程式埋下隱患。

相關推薦

資料倉庫設計的隱患-標量子查詢

首先，來理解一下標量子查詢：處於select之後from之前的子查詢稱為標量子查詢 .比如：select  num1,cal,(select name from t2 where t2.id = t1.id)from t1；舉這個例子只是為了方便理解標量的含義。當然定義為返

徹底搞懂oracle的標量子查詢

article pop acc 問題 content 狀態 cat tracking varchar2 oracle標量子查詢和自己定義函數有時用起來比較方便，並且開發者也常常使用。數據量小還無所謂。數據量大，往往存在性能問題。 下面測試幫助大家徹底搞懂標量子查

SELECT列表中的標量子查詢

我們講到可以將標量子查詢當成SELECT列表中的一個列，唯一的約束就是子查詢的返回值必須只有一行記錄，而且只能有一個列。看完上章的例子有的讀者可能認為標量子查詢只能返回唯一的值，其實標量子查詢完全可以返回隨當前查詢記錄而變化的值。比如下面的SQL語句可以清楚的說明這一點： SELECT FId,FNam

WHERE 子句中的標量子查詢

標量子查詢不僅可以用在SELECT 語句的列表中，它還可以用在WHERE 子句中，而且實際應用中子查詢很多的時候都是用在WHERE子句中的。 先來看一個簡單的例子，我們要檢索喜歡“Story”的讀者主鍵列表，那麼這可以使用連線來完成，不過這裡我們將使用子查詢來完成。 使用子查詢的實現思路也比使用連線簡單。

【網站點選流資料分析】05-資料倉庫設計

採用星型模型  1、事實表 原始資料表:t_origin_weblog valid string 是否有效

大資料模組開發----資料倉庫設計

1． 維度建模基本概念 維度建模(dimensional modeling)是專門用於分析型資料庫、資料倉庫、資料集市建模的方法。資料集市可以理解為是一種"小型資料倉庫"。 維度表(dimension) 維度表示你要對資料進行分析時所用的一個量,比如你要分析產品銷售情況

資料倉庫設計規範

名詞 名詞簡稱 名詞解釋 Data Warehouse DW 資料倉庫主體 Operational Data Store ODS

改寫優化SQL（1）：標量子查詢改為left join

標量子查詢就是在select中出現的子查詢，效率相對來說比較低，建議修改為效率更高的left join。 一、建表 CREATE TABLE tb_emp ( emp_id INT NOT NULL PRIMARY KEY CLUSTERED, emp_name VARC

sql 標量子查詢

返回結果只有一行的查詢叫標量子查詢. SELECT shohin_mei shohin_bunrui FROM Shohin WHERE hanbai_tanka > (SELECT AVG(hanbai_tanka) FROM Shohin); 標量子查詢可以

標量子查詢SQL改寫

SELECT STATEMENT | | 5 | 670 | 14 (8)| 00:00:01 | | 1 | SORT AGGREGATE |

mysql 標量子查詢，多表子查詢，及其效能測評

1. 解釋    標量子查詢希望得到自己所期望的查詢值，多值子查詢是期望產生一個結果的結合。   標量子查詢   如  庫中有表   當我們查詢使用語句 select * from teacher a WHERE a.id in (SELECT id  from stu

標量子查詢優化外連線

同事發來2個語句，說語句1跑得慢，語句2很快就出結果。一執行，果然很慢。仔細發現，2個語句不等價。 語句1：select l.*,o.object_name from v$locked_object l left join all_objects o on l.objec

分散式資料倉庫實戰指南-張子良-專題視訊課程

分散式資料倉庫實戰指南—148人已學習 課程介紹        基於實踐經驗總結，面向資料倉庫中從業人員的一門能力進階課程。涵蓋：資料戰略規劃、資料倉庫模型設計、分散式資料倉庫系統架構、分散式資料儲存模型和分散式i資料倉庫關鍵技術五大技術專題。課程收益    1.戰略規劃篇：

資料庫正規化, 資料倉庫設計架構Kimball 和 Inmon 雜記

關係型資料庫的三大正規化:第一正規化（1NF）是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。第二正規化（2NF）是資料庫規範化中所使用的一種正規形式。它的規則是在1NF的基礎上要求資料表裡的所有資料都要

[數倉]資料倉庫設計方案

資料倉庫設計方案 一.概述  資料倉庫的特徵在於面向主題、整合性、穩定性和時變性，用於支援管理決策。資料倉庫的存在的意義在於對企業的所有資料進行彙總，為企業各個部門提供統一的、規範的資料出口。資料倉庫在構建過程中通常都需要進行分層處理。業務不同，分層的技術處理手段也不同。數倉分層的主要原因： 清晰資料結構

mysql 資料操作 子查詢 帶EXISTS關鍵字的子查詢

  帶EXISTS關鍵字的子查詢   EXISTS關字鍵字表示存在。   EXISTS 判斷某個sql語句的有沒有查到結果 有就返回真  true 否則返回假 False 如果條件成立 返回另外一條sql語句的返回結果   返回結果了 &nb

mysql 資料操作 子查詢 帶比較運算子的子查詢

    帶比較運算子的子查詢   #比較運算子：=、!=、>、>=、<、<=、<> #查詢大於所有人平均年齡的員工名與年齡思路 先拿到所有人的平均年齡然後 再用另外一條sql語句 進行比較 拿所有員工的年齡 > 所有人的平均年齡

【資料倉庫】6. ETL 的設計

0x00 前言 資料倉庫體系裡面的主要內容也寫的差不多了，現在補一點之前遺漏的點。這一篇就來聊一下 ETL。 文章結構 先聊一下什麼是 ETL。 聊一下大致的概念和一般意義上的理解。 聊一聊資料流是什麼樣子。因為 ETL 的工作主要會體現在一條條的資料處理流上，因此這裡做一個

資料庫_子查詢_資料準備

SQL語句允許將一個查詢語句做為一個結果集供其他SQL語句使用，就像使用普通的表一樣，被當作結果集的查詢語句被稱為子查詢。所有可以使用表的地方几乎都可以使用子查詢來代替，比如SELECT FROM T 中就可以用子查詢來代替表T，比如SELECTFROM(SELECT FROM T2 wh

資料結構 筆記：KMP子串查詢演算法

發現 -匹配失敗時的右移位數與子串本身相關，與目標串無關 -移動位數=已匹配的字元數-對應的部分匹配值 -任意子串都穿在一個唯一的部位匹配表 字首 -除了最後一個字元以外，一個字串的全部頭部組合 字尾 -出了第一個字元以外，一個字串的全部尾部組合 部分匹配值 -字