2. 程式人生 > >優化案例4----錯誤的大表走HASH+並行----->正確的走Nested loop

優化案例4----錯誤的大表走HASH+並行----->正確的走Nested loop

阿新 • • 發佈：2019-01-10

       談到大表與大表之間的連線方式，總會下意識的選擇走HASH JOIN+並行效率才高，其實具體情況必須具體問題，在有的時候，大表走巢狀迴圈的效率要優於走HASH JOIN，下面就用我之前優化過的一個案例來說明。

      一個哥們找我優化一個SQL  跑的很慢，103萬個邏輯讀，103萬個物理讀，要跑19秒才能跑完。

     下面是它的SQL 以及執行計劃：

SELECT "A1"."SERV_ID"
   ,"A1"."ATTR_ID"
   ,"A1"."ATTR_VAL"
   ,"A1"."EFF_DATE"
   ,NVL("A1"."EXP_DATE", TO_DATE(NULL, NULL))
   ,"A2"."OP_SEQ"
   ,"A2"."OP_TYPE"
FROM COMM."USER_INFO_OPLOG_MASTER2" "A2"
   ,COMM."SERV_ATTR" "A1"
WHERE "A2"."MEMOP_DATE" IS NULL
   AND "A2"."TABLE_NAME" = 'SERV_ATTR'
   AND "A1"."SERV_ID" = "A2"."TABLE_COLUMN_1"
   AND "A1"."AGREEMENT_ID" = "A2"."TABLE_COLUMN_2"
   AND "A1"."ATTR_ID" = "A2"."TABLE_COLUMN_3"
ORDER BY "A2"."OP_SEQ"

563 rows selected.

Elapsed: 00:00:19.50

Execution Plan
----------------------------------------------------------
Plan hash value: 669020553

---------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
---------------------------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                             |   150K|    17M|       | 61528   (3)| 00:12:19 |        |      |            |
|   1 |  PX COORDINATOR                      |                             |       |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (ORDER)                 | :TQ10002                    |   150K|    17M|       | 61528   (3)| 00:12:19 |  Q1,02 | P->S | QC (ORDER) |
|   3 |    SORT ORDER BY                     |                             |   150K|    17M|    20M| 61528   (3)| 00:12:19 |  Q1,02 | PCWP |            |
|   4 |     PX RECEIVE                       |                             |   150K|    17M|       | 61526   (3)| 00:12:19 |  Q1,02 | PCWP |            |
|   5 |      PX SEND RANGE                   | :TQ10001                    |   150K|    17M|       | 61526   (3)| 00:12:19 |  Q1,01 | P->P | RANGE      |
|*  6 |       HASH JOIN                      |                             |   150K|    17M|       | 61526   (3)| 00:12:19 |  Q1,01 | PCWP |            |
|   7 |        BUFFER SORT                   |                             |       |       |       |            |          |  Q1,01 | PCWC |            |
|   8 |         PX RECEIVE                   |                             |   147K|    11M|       |  1069   (1)| 00:00:13 |  Q1,01 | PCWP |            |
|   9 |          PX SEND BROADCAST           | :TQ10000                    |   147K|    11M|       |  1069   (1)| 00:00:13 |        | S->P | BROADCAST  |
|  10 |           TABLE ACCESS BY INDEX ROWID| USER_INFO_OPLOG_MASTER2     |   147K|    11M|       |  1069   (1)| 00:00:13 |        |      |            |
|* 11 |            INDEX RANGE SCAN          | IDX_INFO_OPLOG_M2COMB_11502 |  6113 |       |       |    33   (0)| 00:00:01 |        |      |            |
|  12 |        PX BLOCK ITERATOR             |                             |   229M|  9427M|       | 60101   (2)| 00:12:02 |  Q1,01 | PCWC |            |
|* 13 |         TABLE ACCESS FULL            | SERV_ATTR                   |   229M|  9427M|       | 60101   (2)| 00:12:02 |  Q1,01 | PCWP |            |
---------------------------------------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   6 - access("A1"."SERV_ID"="A2"."TABLE_COLUMN_1" AND "A1"."AGREEMENT_ID"="A2"."TABLE_COLUMN_2" AND "A1"."ATTR_ID"="A2"."TABLE_COLUMN_3")
  11 - access("A2"."MEMOP_DATE" IS NULL AND "A2"."TABLE_NAME"='SERV_ATTR')
       filter("A2"."TABLE_NAME"='SERV_ATTR')
  13 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"A1"."SERV_ID","A1"."AGREEMENT_ID","A1"."ATTR_ID"))

Note
-----
   - dynamic sampling used for this statement (level=6)


Statistics
----------------------------------------------------------
         30  recursive calls
          0  db block gets
    1039308  consistent gets
    1003269  physical reads
        716  redo size
      31187  bytes sent via SQL*Net to client
        927  bytes received via SQL*Net from client
         39  SQL*Net roundtrips to/from client
         11  sorts (memory)
          0  sorts (disk)
        563  rows processed

    從執行計劃來看 有大概3個問題：

<1> 原SQL並未用hint paraller 提示走並行，但是從實際的執行計劃來看，還是走了並行，應該是這兩張表上設定了預設的並行度。一般可以在資料倉庫裡面這樣搞，但是問了一下這個哥們，他們的資料庫系統是OLTP和OLAP混合系統，因此不建議在表上設定較高的並行度，這樣會促使CBO更加傾向於選擇走並行+全表掃描。

 <2> ID=13 的謂詞資訊有了“(SYS_OP_BLOOM_FILTER(:BF0000,"A1"."SERV_ID","A1"."AGREEMENT_ID","A1"."ATTR_ID"))” ，從10g R2 以後 CBO 優化器演算法加入了布隆過濾演算法，一般在兩表走HASH JOIN+並行的時候會在HASH JOIN的被驅動表中出現，但是從我之前優化過SQL的經驗來看，這個新特性帶了的BUG較多，尤其在被驅動表資料量特別大的時候使用該演算法影響會更大，因此，建議資料系統解決 將該引數disable掉。

<3>  可以看到這個SQL最終返回的結果只有563行，由此推斷，走Nested loop 巢狀迴圈應該會比有HASH 效率更高效。

下面我通過以下SQL 印證了我的判斷：

A2 ------USER_INFO_OPLOG_MASTER2  這個表的總資料量為：67萬條

A1-------SERV_ATTR            這個表的總資料量為：2億多條

執行SQL：

select count(*) from COMM.USER_INFO_OPLOG_MASTER2 where MEMOP_DATE is null and TABLE_NAME='SERV_ATTR';

結果為：    

COUNT(*)
----------
     53677

A2 這個表過濾以後只返回5萬多條

再來看A1 表中索引的資訊：

****************************************************************************************
INDEX INFO
****************************************************************************************

TABLE           TABLE                               Index                                    COLUMN                     Col
OWNER           NAME                                Name                           Unique    NAME                       Pos DESC
--------------- ----------------------------------- ------------------------------ --------- ------------------------- ---- ----
COMM            SERV_ATTR                           IDX_SERV_ATTR_AGREEMENT_ID     NONUNIQUE AGREEMENT_ID                 1 ASC
                                                    IDX_SERV_ATTR_ATTR_ID          NONUNIQUE ATTR_ID                      1 ASC
                                                    IDX_SERV_ATTR_INTERNET         NONUNIQUE ATTR_VAL                     1 ASC
                                                                                             ATTR_ID                      2 ASC
                                                    IDX_SERV_ATTR_SERV_ID          NONUNIQUE SERV_ID                      1 ASC
                                                    IDX_SERV_ATTR_VAL8             NONUNIQUE ATTR_VAL                     1 ASC
                                                    PK_SERV_ATTR                   UNIQUE    SERV_ID                      1 ASC
                                                                                             AGREEMENT_ID                 2 ASC
                                                                                             ATTR_ID                      3 ASC

A1表有個聯合主鍵 建立在了：SERV_ID   AGREEMENT_ID    ATTR_ID  這三列上，而看SQL 這三列恰恰是A1與A2的連線列，那就好辦了 ，我讓A2做巢狀迴圈的驅動表，A1 做被驅動表，那麼A1 一定走的是通過主鍵PK_SERV_ATTR 走索引唯一掃描然後回表，效能不會太低。

我讓它加下以下的HINT 然後去set autotrace traceonly  去看執行計劃和邏輯讀：

/*+ use_nl(A1,A2)  index(A1,PK_SERV_ATTR) leading(A2)  */

Elapsed: 00:00:05.45

Execution Plan
----------------------------------------------------------
Plan hash value: 4263321111

----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                        | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                             |   142K|    16M|       |   286K  (1)| 00:57:13 |
|   1 |  SORT ORDER BY                 |                             |   142K|    16M|    19M|   286K  (1)| 00:57:13 |
|   2 |   NESTED LOOPS                 |                             |   142K|    16M|       |   282K  (1)| 00:56:26 |
|   3 |    NESTED LOOPS                |                             |   142K|    16M|       |   282K  (1)| 00:56:26 |
|   4 |     TABLE ACCESS BY INDEX ROWID| USER_INFO_OPLOG_MASTER2     |   140K|    10M|       |  1489   (1)| 00:00:18 |
|*  5 |      INDEX RANGE SCAN          | IDX_INFO_OPLOG_M2COMB_11502 |  9438 |       |       |    49   (0)| 00:00:01 |
|*  6 |     INDEX UNIQUE SCAN          | PK_SERV_ATTR                |     1 |       |       |     2   (0)| 00:00:01 |
|   7 |    TABLE ACCESS BY INDEX ROWID | SERV_ATTR                   |     1 |    43 |       |     3   (0)| 00:00:01 |
----------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   5 - access("A2"."TABLE_NAME"='SERV_ATTR' AND "A2"."MEMOP_DATE" IS NULL)
   6 - access("A1"."SERV_ID"="A2"."TABLE_COLUMN_1" AND "A1"."AGREEMENT_ID"="A2"."TABLE_COLUMN_2" AND
              "A1"."ATTR_ID"="A2"."TABLE_COLUMN_3")

Note
-----
   - dynamic sampling used for this statement (level=6)


Statistics
----------------------------------------------------------
          7  recursive calls
          0  db block gets
      60044  consistent gets
       5440  physical reads
       8824  redo size
      19160  bytes sent via SQL*Net to client
        762  bytes received via SQL*Net from client
         24  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
        345  rows processed

最終5秒就跑完了，邏輯讀從之前的103萬減少到了6萬。

相關推薦

優化案例4----錯誤的大表走HASH+並行----->正確的走Nested loop

       談到大表與大表之間的連線方式，總會下意識的選擇走HASH JOIN+並行效率才高，其實具體情況必須具體問題，在有的時候，大表走巢狀迴圈的效率要優於走HASH JOIN，下面就用我之前優化過的一個案例來說明。       一個哥們找我優化一個SQL  跑的很慢，

MySQL SQL 優化案例：JOIN派生表

優化之前： SELECT ap.institution_id, date(ra.create_time) date, sum( IF ( ra.confirm_amount > ld.debit_amount, ld.d

4錯誤大總結

1.用0到9十個數字構造一個二級目錄，每個目錄名字有2位數字如00/79並把所有的目錄打印出來 2.寫出幾種抓取遠端程式的幾種方法？（file_get——contents的第二個引數是？） 3.使用css 來隱藏一個div的方法? 4.php沒有安裝xml用什麼方法能夠解析

多表連線的三種方式詳解 HASH JOIN MERGE JOIN NESTED LOOP

在多表聯合查詢的時候，如果我們檢視它的執行計劃，就會發現裡面有多表之間的連線方式。 之前打算在sqlplus中用執行計劃的，但是格式看起來有點亂，就用Toad 做了3個截圖。  

多表連線的三種方式詳解 HASH JOIN MERGE JOIN NESTED LOOP【3】

SQL server 內部實現了三種類型的內連線運算，大多數人從來沒有聽說過這些連線型別，因為它們不是邏輯連線也很少被用於程式碼中。那麼它們什麼時候會被用到呢？答案是要依情況而定。這就意味著要依賴於記錄集和索引。查詢優化器總是智慧的選擇最優的物理連線型別。我們知道SQL優

Django-website 程序案例系列-18 多表跨表操作優化

query n-n none plain pro 三種 wrap 減少 緩存 詳解Django的 select_related 和 prefetch_related 函數對 QuerySet 查詢的優化 在數據庫有外鍵的時候，使用 select_related() 和

Mysql千萬級大表優化

數據庫服務 時間段 系統 時也 導致 slave 如何 1.5 傳統 Mysql的單張表的最大數據存儲量尚沒有定論，一般情況下mysql單表記錄超過千萬以後性能會變得很差。因此，總結一些相關的Mysql千萬級大表的優化策略。 1.優化sql以及索引 1.1優化sql

千萬級的大表！MySQL這樣優化更好

cached linux l數據庫 效果 pin 控制 img red 存儲引擎 對於一個千萬級的大表，現在可能更多的是億級數據量，很多人第一反應是各種切分，可結果總是事半功倍，或許正是我們優化順序的不正確。下面我們來談談怎樣的優化順序可以讓效果更好。 MySQL數據

MySQL大表優化方案

基於用戶 保存 優先 完成 優化方案 想要 存儲 addition 精確 MySQL大表優化方案 mysql 168 當MySQL單表記錄數過大時，增刪改查性能都會急劇下降，可以參考以下步驟

案例解析・4步驟大段文字變身為PPT

在製作PPT的時候，我們經常需要將一大段的文字轉換為PPT。面對這種需求，很多人都會有一種無從下手的感覺，今天我們就通過兩個案例，給大家介紹通過4個步驟讓大段文字變身為PPT。 上週我給深圳供電局的同事們做了一場關於PPT課件製作技巧的培訓。在準備課程的時候，我按照慣例到深圳供電局的官網，找素材來設

MySQL千萬級大表優化解決方案

MySQL千萬級大表優化解決方案 非原創，純屬記錄一下。 背景 無意間看到了這篇文章，作者寫的很棒，於是乎，本人自私一把，把乾貨儲存下來。:-) 問題概述 使用阿里雲rds for MySQL資料庫（就是MySQL5.6版本），有個使用者上網記錄表6個月的資料量近2000萬，保留最近一年的資料量達到

Oracle SQL效能優化 - 根據大表關聯更新小表

需求： 　　小表資料量20w條左右，大表資料量在4kw條左右，需要根據大表篩選出150w條左右的資料並關聯更新小表中5k左右的資料。 效能問題： 對篩選條件中涉及的欄位加index後，如下常規的update語句仍耗時半小時左右。 UPDATE WMOCDCREPORT.DM_WM_TRADI

乾貨！！！MySQL 大表優化方案（1）

當MySQL單表記錄數過大時，增刪改查效能都會急劇下降，可以參考以下步驟來優化： 單表優化 除非單表資料未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下是沒有太大問題

SQL優化案例-單表分頁語句的優化（八）

分頁語句分為單表分頁與多表關聯分頁。分頁語句的優化首先要選對分頁框架，錯誤的分頁框架會導致掃描表中全部的資料，正確的分頁框架會利用到rownum的count stopkey特性較少資料訪問。 如下錯誤的分頁框架： SELECT * FROM (SELECT T.*, ROWNUM RN

優秀後端架構師必會知識：史上最全MySQL大表優化方案總結

本文原作者“ manong”，原創發表於segmentfault，原文連結：segmentfault.com/a/1190000006158186 1、引言 MySQL作為開源技術的代表作之一，是網際網路得以廣泛流行的重要基礎技術之一。 國外 GitHub、Airbnb、Yelp、

Oracle優化器、優化模式、表的連線方式（Hash Join、Nested Loop、Sort Merge Join）

查詢優化器 Oracle的查詢優化器（QO）分為兩種： 1. RBO：Ruled-Based Optimization， 基於規則的優化器； 2. CBO ：Cost-Based Optimization， 基於代價的優化器； 從 Orac

MySQL 對於千萬級的大表要怎麼優化

千萬級，MySQL實際上確實不是什麼壓力，InnoDB的儲存引擎，使用的是B+樹儲存結構，千萬級的資料量，基本也就是三到四層的搜尋，如果有合適的索引，效能基本也不是問題。 但經常出現的情況是，業務上面的增長，導致資料量還會繼續增長，為了應對這方面的問題而必須要做擴充套件了此時可能首先需要考慮的就是分表策略

MySQL 對於千萬級的大表要怎麼優化？（讀寫分離、水平拆分、垂直拆分）

思考 如何設計或優化千萬級別的大表？此外無其他資訊，個人覺得這個話題有點範，就只好簡單說下該如何做，對於一個儲存設計，必須考慮業務特點，收集的資訊如下： 1.資料的容量：1-3年內會大概多少條資料，每條資料大概多少位元組； 2.資料項：是否有大欄位，那些欄位的值是否經常

MySQL 大表優化方案（長文）

當MySQL單表記錄數過大時，增刪改查效能都會急劇下降，可以參考以下步驟來優化：單表優化除非單表資料未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下是沒有太大問題的。而事實上很多時候MySQL單表的效能依然有不少優

MySQL 大表優化方案

當MySQL單表記錄數過大時，增刪改查效能都會急劇下降，可以參考以下步驟來優化： 單表優化 除非單表資料未來會一直不斷上漲，否則不要一開始就考慮拆分，拆分會帶來邏輯、部署、運維的各種複雜度，一般以整型值為主的表在千萬級以下，字串為主的表在五百萬以下