使用UNION代替OR 提升查詢效能

阿新 • • 發佈：2018-12-23

昨天一位鐵哥們通過QQ找我幫忙，問下面這個SQL能否優化

SQL> set timing on
SQL> set autotrace on
SQL> select count(*) rowcount_lhy
  2    from swgl_ddjbxx t
  3   where t.fzgs_dm = '001085'
  4     and (t.lrr_dm = 'e90e3fe4237c4af988477329c7f2059e' or exists
  5          (select y.kh_id
  6             from khgl_khywdlxx y
  7            where y.kh_id = t.kh_id
  8              and y.sskhjl_dm = 'e90e3fe4237c4af988477329c7f2059e') or
  9          t.kpr_dm = 'e90e3fe4237c4af988477329c7f2059e')
 10     and t.xjbz = '9999'
 11     and t.FROMNBGL1 = '0';

 

SQL> set line  300
SQL> /

ROWCOUNT_LHY
------------
          60

已用時間:  00: 00: 20.53

執行計劃
----------------------------------------------------------
Plan hash value: 1217125969

--------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                        |     1 |    86 | 28048   (1)| 00:05:37 |
|   1 |  SORT AGGREGATE               |                        |     1 |    86 |            |          |
|*  2 |   FILTER                      |                        |       |       |            |          |
|*  3 |    TABLE ACCESS FULL          | SWGL_DDJBXX            |  5926 |   497K| 28048   (1)| 00:05:37 |
|*  4 |    TABLE ACCESS BY INDEX ROWID| KHGL_KHYWDLXX          |     1 |    57 |     5   (0)| 00:00:01 |
|*  5 |     INDEX RANGE SCAN          | IDX_KHGL_KHYWDLXX_KHID |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

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

   2 - filter("T"."LRR_DM"='e90e3fe4237c4af988477329c7f2059e' OR
              "T"."KPR_DM"='e90e3fe4237c4af988477329c7f2059e' OR  EXISTS (SELECT 0 FROM "KHGL_KHYWDLXX" "Y"
              WHERE "Y"."KH_ID"=:B1 AND "Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e'))
   3 - filter("T"."FROMNBGL1"='0' AND "T"."XJBZ"='9999' AND "T"."FZGS_DM"='001085')
   4 - filter("Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e')
   5 - access("Y"."KH_ID"=:B1)


統計資訊
----------------------------------------------------------
          0  recursive calls
          0  db block gets
     804560  consistent gets
      71127  physical reads
          0  redo size
        516  bytes sent via SQL*Net to client
        469  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

看了5秒鐘，回覆哥們說把or展開成union,但是那哥們SQL確實太菜了呵呵(別罵我哈)，只好幫忙寫一個了

SQL> select count(*)
  2    from (select *
  3            from swgl_ddjbxx t
  4           where t.lrr_dm = 'e90e3fe4237c4af988477329c7f2059e'
  5             and t.fzgs_dm = '001085'
  6             and t.xjbz = '9999'
  7             and t.FROMNBGL1 = '0'
  8          union
  9          select *
 10            from swgl_ddjbxx t
 11           where t.kpr_dm = 'e90e3fe4237c4af988477329c7f2059e'
 12             and t.fzgs_dm = '001085'
 13             and t.xjbz = '9999'
 14             and t.FROMNBGL1 = '0'
 15          union
 16          select *
 17            from swgl_ddjbxx t
 18           where exists
 19           (select y.kh_id
 20                    from khgl_khywdlxx y
 21                   where y.kh_id = t.kh_id
 22                     and y.sskhjl_dm = 'e90e3fe4237c4af988477329c7f2059e')
 23             and t.fzgs_dm = '001085'
 24             and t.xjbz = '9999'
 25             and t.FROMNBGL1 = '0');

  COUNT(*)
----------
        60

已用時間:  00: 00: 06.89

執行計劃
----------------------------------------------------------
Plan hash value: 3846872744

-----------------------------------------------------------------------------------------------------------------------
| Id  | Operation                          | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |                          |     1 |       |       | 52263   (1)| 00:10:28 |
|   1 |  SORT AGGREGATE                    |                          |     1 |       |       |         |             |
|   2 |   VIEW                             |                          |  5996 |       |       | 52263   (1)| 00:10:28 |
|   3 |    SORT UNIQUE                     |                          |  5996 |  2238K|  6344K| 52263  (47)| 00:10:28 |
|   4 |     UNION-ALL                      |                          |       |       |       |         |             |
|*  5 |      TABLE ACCESS FULL             | SWGL_DDJBXX              |    59 | 19234 |       | 28037   (1)| 00:05:37 |
|*  6 |      TABLE ACCESS BY INDEX ROWID   | SWGL_DDJBXX              |    10 |  3260 |       |  1209   (1)| 00:00:15 |
|*  7 |       INDEX RANGE SCAN             | IDX_SWGL_DDJBXX_KPRDM    |  4748 |       |       |    34   (0)| 00:00:01 |
|*  8 |      TABLE ACCESS BY INDEX ROWID   | SWGL_DDJBXX              |     1 |   326 |       |     5   (0)| 00:00:01 |
|   9 |       NESTED LOOPS                 |                          |  5927 |  2216K|       | 22527   (1)| 00:04:31 |
|  10 |        SORT UNIQUE                 |                          | 10165 |   565K|       |  1916   (1)| 00:00:23 |
|  11 |         TABLE ACCESS BY INDEX ROWID| KHGL_KHYWDLXX            | 10165 |   565K|       |  1916   (1)| 00:00:23 |
|* 12 |          INDEX RANGE SCAN          | IDX_KHGL_KHYWDLXX_SSKHJL | 10165 |       |       |   111   (0)| 00:00:02 |
|* 13 |        INDEX RANGE SCAN            | IDX_SWGL_DDJBXX_KHID     |     2 |       |       |     2   (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------

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

   5 - filter("T"."LRR_DM"='e90e3fe4237c4af988477329c7f2059e' AND "T"."FROMNBGL1"='0' AND "T"."XJBZ"='9999'
              AND "T"."FZGS_DM"='001085')
   6 - filter("T"."FROMNBGL1"='0' AND "T"."XJBZ"='9999' AND "T"."FZGS_DM"='001085')
   7 - access("T"."KPR_DM"='e90e3fe4237c4af988477329c7f2059e')
   8 - filter("T"."FROMNBGL1"='0' AND "T"."XJBZ"='9999' AND "T"."FZGS_DM"='001085')
  12 - access("Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e')
  13 - access("Y"."KH_ID"="T"."KH_ID")


統計資訊
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     128422  consistent gets
      10308  physical reads
          0  redo size
        512  bytes sent via SQL*Net to client
        469  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          2  sorts (memory)
          0  sorts (disk)
          1  rows processed

SQL改寫之後，執行時間由原來的20秒下降到6秒，邏輯讀由804560降低到128422，效能還是有很大提升的，到了這裡優化還沒完，可以建立一個組合索引進一步優化

create index idx on swgl_ddjbxx(fzgs_dm,xjbz,FROMNBGL1);

建立索引之後，原始的SQL執行時間，執行計劃，統計資訊如下：

SQL> select count(*) rowcount_lhy
  2    from swgl_ddjbxx t
  3   where t.fzgs_dm = '001085'
  4     and (t.lrr_dm = 'e90e3fe4237c4af988477329c7f2059e' or exists
  5          (select y.kh_id
  6             from khgl_khywdlxx y
  7            where y.kh_id = t.kh_id
  8              and y.sskhjl_dm = 'e90e3fe4237c4af988477329c7f2059e') or
  9          t.kpr_dm = 'e90e3fe4237c4af988477329c7f2059e')
 10     and t.xjbz = '9999'
 11     and t.FROMNBGL1 = '0';

ROWCOUNT_LHY
------------
          60

已用時間:  00: 00: 02.96

執行計劃
----------------------------------------------------------
Plan hash value: 3049366449

--------------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                        |     1 |    86 |   506   (0)| 00:00:07 |
|   1 |  SORT AGGREGATE               |                        |     1 |    86 |            |          |
|*  2 |   FILTER                      |                        |       |       |            |          |
|   3 |    TABLE ACCESS BY INDEX ROWID| SWGL_DDJBXX            |  5926 |   497K|   506   (0)| 00:00:07 |
|*  4 |     INDEX RANGE SCAN          | IDX                    |  2370 |       |    12   (0)| 00:00:01 |
|*  5 |    TABLE ACCESS BY INDEX ROWID| KHGL_KHYWDLXX          |     1 |    57 |     5   (0)| 00:00:01 |
|*  6 |     INDEX RANGE SCAN          | IDX_KHGL_KHYWDLXX_KHID |     1 |       |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------------------------------------

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

   2 - filter("T"."LRR_DM"='e90e3fe4237c4af988477329c7f2059e' OR
              "T"."KPR_DM"='e90e3fe4237c4af988477329c7f2059e' OR  EXISTS (SELECT 0 FROM "KHGL_KHYWDLXX" "Y"
              WHERE "Y"."KH_ID"=:B1 AND "Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e'))
   4 - access("T"."FZGS_DM"='001085' AND "T"."XJBZ"='9999' AND "T"."FROMNBGL1"='0')
   5 - filter("Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e')
   6 - access("Y"."KH_ID"=:B1)


統計資訊
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     702767  consistent gets
          0  physical reads
          0  redo size
        516  bytes sent via SQL*Net to client
        469  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

改寫的SQL：

SQL> select count(*)
  2    from (select *
  3            from swgl_ddjbxx t
  4           where t.lrr_dm = 'e90e3fe4237c4af988477329c7f2059e'
  5             and t.fzgs_dm = '001085'
  6             and t.xjbz = '9999'
  7             and t.FROMNBGL1 = '0'
  8          union
  9          select *
 10            from swgl_ddjbxx t
 11           where t.kpr_dm = 'e90e3fe4237c4af988477329c7f2059e'
 12             and t.fzgs_dm = '001085'
 13             and t.xjbz = '9999'
 14             and t.FROMNBGL1 = '0'
 15          union
 16          select *
 17            from swgl_ddjbxx t
 18           where exists
 19           (select y.kh_id
 20                    from khgl_khywdlxx y
 21                   where y.kh_id = t.kh_id
 22                     and y.sskhjl_dm = 'e90e3fe4237c4af988477329c7f2059e')
 23             and t.fzgs_dm = '001085'
 24             and t.xjbz = '9999'
 25             and t.FROMNBGL1 = '0');

  COUNT(*)
----------
        60

已用時間:  00: 00: 00.53

執行計劃
----------------------------------------------------------
Plan hash value: 2947849958

-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                            | Name                     | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                     |                          |     1 |       |       |  3469   (1)| 00:00:42 |
|   1 |  SORT AGGREGATE                      |                          |     1 |       |       |         |             |
|   2 |   VIEW                               |                          |  5995 |       |       |  3469   (1)| 00:00:42 |
|   3 |    SORT UNIQUE                       |                          |  5995 |  2238K|  4760K|  3469  (86)| 00:00:42 |
|   4 |     UNION-ALL                        |                          |       |       |       |         |             |
|*  5 |      TABLE ACCESS BY INDEX ROWID     | SWGL_DDJBXX              |    59 | 19234 |       |   506   (0)| 00:00:07 |
|*  6 |       INDEX RANGE SCAN               | IDX                      |  2370 |       |       |    12   (0)| 00:00:01 |
|   7 |      TABLE ACCESS BY INDEX ROWID     | SWGL_DDJBXX              |    10 |  3260 |       |    50   (0)| 00:00:01 |
|   8 |       BITMAP CONVERSION TO ROWIDS    |                          |       |       |       |         |             |
|   9 |        BITMAP AND                    |                          |       |       |       |         |             |
|  10 |         BITMAP CONVERSION FROM ROWIDS|                          |       |       |       |         |             |
|* 11 |          INDEX RANGE SCAN            | IDX                      |  2370 |       |       |    12   (0)| 00:00:01 |
|  12 |         BITMAP CONVERSION FROM ROWIDS|                          |       |       |       |         |             |
|* 13 |          INDEX RANGE SCAN            | IDX_SWGL_DDJBXX_KPRDM    |  2370 |       |       |    34   (0)| 00:00:01 |
|* 14 |      HASH JOIN RIGHT SEMI            |                          |  5926 |  2216K|       |  2423   (1)| 00:00:30 |
|  15 |       TABLE ACCESS BY INDEX ROWID    | KHGL_KHYWDLXX            | 10165 |   565K|       |  1916   (1)| 00:00:23 |
|* 16 |        INDEX RANGE SCAN              | IDX_KHGL_KHYWDLXX_SSKHJL | 10165 |       |       |   111   (0)| 00:00:02 |
|  17 |       TABLE ACCESS BY INDEX ROWID    | SWGL_DDJBXX              |  5926 |  1886K|       |   506   (0)| 00:00:07 |
|* 18 |        INDEX RANGE SCAN              | IDX                      |  2370 |       |       |    12   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------

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

   5 - filter("T"."LRR_DM"='e90e3fe4237c4af988477329c7f2059e')
   6 - access("T"."FZGS_DM"='001085' AND "T"."XJBZ"='9999' AND "T"."FROMNBGL1"='0')
  11 - access("T"."FZGS_DM"='001085' AND "T"."XJBZ"='9999' AND "T"."FROMNBGL1"='0')
       filter("T"."FROMNBGL1"='0' AND "T"."XJBZ"='9999' AND "T"."FZGS_DM"='001085')
  13 - access("T"."KPR_DM"='e90e3fe4237c4af988477329c7f2059e')
  14 - access("Y"."KH_ID"="T"."KH_ID")
  16 - access("Y"."SSKHJL_DM"='e90e3fe4237c4af988477329c7f2059e')
  18 - access("T"."FZGS_DM"='001085' AND "T"."XJBZ"='9999' AND "T"."FROMNBGL1"='0')


統計資訊
----------------------------------------------------------
          1  recursive calls
          0  db block gets
      25628  consistent gets
          0  physical reads
          0  redo size
        512  bytes sent via SQL*Net to client
        469  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          1  rows processed

由於我不能直接連線到DB，這個SQL的優化就到此為止。

使用UNION代替OR 提升查詢效能

昨天一位鐵哥們通過QQ找我幫忙，問下面這個SQL能否優化 SQL> set timing on SQL> set autotrace on SQL> select count(*) rowcount_lhy 2 from swgl_ddjbxx

Greenplum 點查(按PK查詢)效能與提升空間

標籤 PostgreSQL , Greenplum , 點查 , 按PK查詢背景點查，基於PK的查詢或者OLTP類查詢，實際上並不是GPDB 擅長的，GPDB擅長的是海量的OLAP。不過在企業、政府等視窗服務類業務，併發實際上並不高，如果GPDB的點查效能達到一定的效能時，

用Redis快取來提升資料庫查詢效能

對一個關係型資料庫進行調優以獲得高查詢效能可能會比較困難。如果對資料模型優化和對查詢調優不起作用，DBA就可以使用快取系統，比如Redis，它是一個可以提供記憶體和永久資料儲存的鍵值資料儲存系統。由於Redis能夠將資料快速讀寫至資料儲存系統，比起關係型資料庫它更具效

在MongoDB中組合使用$or、sort()或$or、$and時，查詢效能可能會很差

單獨使用$or、$and、sort()時，查詢效能均可，但$or與$and或sort()組合查詢，其時長會增加幾倍！！！將來會修改，今天先記錄一下。論壇回覆: I believe the query optimizer is choosing to use

MYSQL索引的使用(使用UNION ALL代替OR)

一個文章庫，裡面有兩個表：category和article。category裡面有10條分類資料。article裡面有20萬條。article裡面有一個"article_category"欄位是與category裡的"category_id"欄位相對應的。article表裡

【宇哥帶你玩轉MySQL】索引篇(一)索引揭祕，看他是如何讓你的查詢效能指數提升的

場景復現，一個索引提高600倍查詢速度？首先準備一張books表 create table books( id int not null primary key auto_increment, name varchar(255) not null, author va

LINQ多條件OR模糊查詢

轉載這樣的 .com 最終 () msdn soci table copy 需求是這樣的，有一張表tbl(Key[int],Value[string])，數據存儲如下： Key Value 1 -a-b- 2 -a- 3 -c-e- 4 -f-g-

Oracle提升查詢性能之-簡單範圍分區表的創建

裝載是你 name val mod 空間關閉自動單個 arch 分區表的優點：1.提高查詢性能：只需要搜索特定分區，而非整張表，提高了查詢速度。 2.節約維護時間：單個分區的數據裝載，索引重建，備份，維護遠遠小於整張表的維護時間。下面就讓我們來創建一張分區表第一步：為

使用ehcache快取頁面、ExpiresFilter新增Expires頭，大幅提升網站效能

前幾天把網站部署到伺服器上後發現訪問速度和龜速差不多，內心感到非常焦慮——之前並未做過這方面的嘗試，要解決問題實在有些頭大。但幸好之前做過一個專案，本地訪問速度感覺奇慢，但正式環境下訪問速度反倒快得飛起。雖然我期初並不知曉原因，但這畢竟是解決問題的線索。追本溯源的找，情況倒也

STL 之 vector 查詢效能優化

如果一個數組元素不多，就沒必要做優化了。這裡要說的是一個大的陣列，在進行遍歷查詢元素的時候，優化和沒有優化的效果還是可以用肉眼看得出來的，下面是一個簡單的例子： // vertor_test.cpp : 定義控制檯應用程式的入口點。 // #include "stdafx.h" #incl

[譯] Google 工程師提升網頁效能的新策略：空閒執行，緊急優先

原文地址：Idle Until Urgent 原文作者：PHILIP WALTON 譯文出自：掘金翻譯計劃本文永久連結：github.com/xitu/gold-m… 譯者：Ivocin 校對者：xilihuasi，新艦同學 Xekin 幾周前，我開始

hibernate抓取策略效能分析，子查詢/連線查詢效能對比

https://blog.csdn.net/qq_40762011/article/details/82993283 https://blog.csdn.net/lzm18064126848/article/details/50578285 https://blog.csdn.net/luckarecs/

MySQL分頁查詢效能優化

當需要從資料庫查詢的表有上萬條記錄的時候，一次性查詢所有結果會變得很慢，特別是隨著資料量的增加特別明顯，這時需要使用分頁查詢。對於資料庫分頁查詢，也有很多種方法和優化的點。下面簡單說一下我知道的一些方法。準備工作為了對下面列舉的一些優化進行測試，下面針對已有的一張表進行說明。表名：order

springboot中提升資料庫效能-redis快取和資料監控

1.最近在看springboot ，簡單做一個記錄一個很強大的工具 -druid 上圖自己體會吧關於redis做快取已經很普通了，給程式碼自己體會下感謝大神：https://github.com/chenfromsz/spring-boot-dbu

Mysql資料庫效能優化之查詢效能優化

一、前言：為啥查詢速度會變慢？通常來說，查詢的生命週期大致分為從客戶端、到伺服器，然後在伺服器上進行解析，生成執行計劃，執行，並返回結果給客戶端。其中執行可以說是最重要的階段，這其中包括了大量為了檢索資料到儲存引擎的呼叫以及呼叫後的資料處理，包括排序和分組等。在每一個消耗大量時間的查

高效能Mysql------------查詢效能優化

查詢優化，索引優化，庫表結構優化需要齊頭並進。查詢效能低下最基本的原因是訪問的資料太多了。可以通過下面兩個步驟來分析： 1.是否檢索大量超過需要的資料 2.是否在分析大量超過需要的資料行請求了不需要的資料 1）查詢不需要的記錄最簡單的解決方法是在查詢後面加limit 2)多

如何提升前端效能和響應速度

如何提升前端效能和響應速度 1. 原生 css 動畫代替 js 動畫原生 css 動畫要比 js 實現的動畫要高效很多，所以在可能的情況下儘量用原生 css 動畫。 2. 原生 js 代替第三方庫因為第三方庫不可避免的會增大打包檔案的體積，並且有很多我們用不著的程式碼和效能的損失

剖析Elasticsearch的IndexSorting:一種查詢效能優化利器

前言前兩週寫過一篇《基於Lucene查詢原理分析Elasticsearch的效能》，在最後留了一個彩蛋，說下一篇會介紹一種可以極大的優化查詢效能的技術。本文就來介紹這種技術——IndexSorting。因為IndexSorting是在ES6.0之後才作為實驗性的功能加入，相關的介紹資料還比較少，所以大

Python霧裡看花-list與set十萬資料查詢效能對比

# -*- coding: utf-8 -*- import random import time num = 100000 listA = [random.randint(1, i) for i in range(1, num)] setB = set() while len(set

union表關聯模糊查詢servlet，action方法

equal manager lis protect and new ati null bsp 2018-11-14 servletxml層 public String getSql(String keyword) { StringBuffer sqlSb

使用UNION代替OR 提升查詢效能

相關推薦