主頁 > 資料庫 > Semi-Join Subquery優化策略

Semi-Join Subquery優化策略

2023-05-07 09:19:40 資料庫

Semi-Join Subquery優化策略

Semi-Join Subquery(半連接子查詢):對應IN或EXISTS子查詢,僅需要檢查"外表記錄"在"子查詢結果集"中是否存在匹配記錄,不需要計算"子查詢結果集"中記錄匹配次數,也不需要回傳"子查詢結果集"中匹配記錄內容

在MariaDB(MySQL)中,常用優化Semi-Join(半連接)的策略有:

  • First Match
  • Table Pullout
  • Semi-join Materialization
  • Loose Scan
  • Duplicate Weedout

First Match策略

當回圈"外部查詢結果集"的每條記錄去"子查詢中"確認"是否匹配"時,只需要找到第一條匹配記錄(First Match)既可跳出子查詢,

如下面查詢:

SELECT * FROM Country 
WHERE Country.code IN (
    SELECT City.Country 
    FROM City 
    WHERE City.Population > 1*1000*1000
)
AND Country.continent='Europe'

如果不使用First Match策略,當處理到Country表上滿足" Country.continent='Europe' "條件的德國(Deu)記錄時,會掃描City表上滿足" City.Population > 110001000 AND City.Country='DEU' "的所有記錄,再根據匹配記錄總數回傳"是否匹配"結果:

如果使用First Match策略,當處理到Country表上滿足" Country.continent='Europe' "條件的德國(Deu)記錄時,會掃描City表上滿足" City.Population > 110001000 AND City.Country='DEU' "的第一條記錄"Berlin"后,立即回傳"是否匹配"結果:

在MariaDB上使用First Match策略的查詢的執行計劃為:

MariaDB [world]> explain select * from Country where Country.code IN (select City.Country from City where City.Population > 1*1000*1000) and Country.continent='Europe';
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
| id | select_type | table   | type | possible_keys      | key       | key_len | ref                | rows | Extra                            |
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
|  1 | PRIMARY     | Country | ref  | PRIMARY,continent  | continent | 17      | const              |   60 | Using index condition            |
|  1 | PRIMARY     | City    | ref  | Population,Country | Country   | 3       | world.Country.Code |   18 | Using where; FirstMatch(Country) |
+----+-------------+---------+------+--------------------+-----------+---------+--------------------+------+----------------------------------+
2 rows in set (0.00 sec)

MariaDB的執行計劃中會有明顯的FirstMatch標識,

在MySQL上使用First Match策略的查詢的執行計劃為:

MySQL [world]> explain select * from Country  where Country.code IN (select City.Country from City where City.Population > 1*1000*1000) and Country.continent='Europe';
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
| id | select_type        | table   | type           | possible_keys      | key       | key_len | ref   | rows | Extra                              |
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
|  1 | PRIMARY            | Country | ref            | continent          | continent | 17      | const |   60 | Using index condition; Using where |
|  2 | DEPENDENT SUBQUERY | City    | index_subquery | Population,Country | Country   | 3       | func  |   18 | Using where                        |
+----+--------------------+---------+----------------+--------------------+-----------+---------+-------+------+------------------------------------+
2 rows in set (0.01 sec)

MariaDB的執行計劃中僅顯示為依賴子查詢(DEPENDENT SUBQUERY)

First Match策略和將IN子查詢轉換為EXISTS依賴子查詢很相似,但兩者還是存在明顯差異,并非所有EXISTS操作都能使用First Match策略,如子查詢中使用GROUP BY相關的聚合函式時,需要先完成GROUP BY操作才能確認"是否匹配",

Table Pullout策略

當子查詢的查詢串列項只有主鍵或唯一索引鍵時,能推算出"子查詢結果集"不存在重復記錄,因此可以將子查詢改為關聯查詢,即將子查詢中的表上提到關聯查詢,

對于查詢:

SELECT *
FROM City 
WHERE City.Country IN (
	SELECT Country.Code
	FROM Country 
	WHERE Country.Population < 100*1000
);

在MariaDB 5.2 和MySQL 5.6版本及之前版本上,執行計劃為:

MySQL [world]> explain select * from City where City.Country in (select Country.Code from Country where Country.Population < 100*1000);
+----+--------------------+---------+-----------------+--------------------+---------+---------+------+------+-------------+
| id | select_type        | table   | type            | possible_keys      | key     | key_len | ref  | rows | Extra       |
+----+--------------------+---------+-----------------+--------------------+---------+---------+------+------+-------------+
|  1 | PRIMARY            | City    | ALL             | NULL               | NULL    | NULL    | NULL | 4079 | Using where |
|  2 | DEPENDENT SUBQUERY | Country | unique_subquery | PRIMARY,Population | PRIMARY | 3       | func |    1 | Using where |
+----+--------------------+---------+-----------------+--------------------+---------+---------+------+------+-------------+
2 rows in set (0.00 sec)

如果Country.Code是主鍵或唯一索引,則可以將SQL改寫為:

SELECT City.* 
FROM City
INNER JOIN Country 
ON City.Country=Country.Code
WHERE Country.Population < 100*1000;

改為關聯查詢后,可以根據兩張關聯表的統計資料來選擇驅動表和被驅動表,因此在MariaDB 5.3或MySQL 5.7版本,執行計劃為:

MariaDB [world]> explain select * from City where City.Country in (select Country.Code from Country where Country.Population < 100*1000);
+----+-------------+---------+-------+--------------------+------------+---------+--------------------+------+-----------------------+
| id | select_type | table   | type  | possible_keys      | key        | key_len | ref                | rows | Extra                 |
+----+-------------+---------+-------+--------------------+------------+---------+--------------------+------+-----------------------+
|  1 | PRIMARY     | Country | range | PRIMARY,Population | Population | 4       | NULL               |   37 | Using index condition |
|  1 | PRIMARY     | City    | ref   | Country            | Country    | 3       | world.Country.Code |   18 |                       |
+----+-------------+---------+-------+--------------------+------------+---------+--------------------+------+-----------------------+
2 rows in set (0.00 sec)

Materialization策略

在使用Table Pullout策略時,需要能明確推算出"子查詢結果集"不存在重復記錄時才能將"子查詢"改為"關聯查詢",如果將"子查詢結果集"通過臨時表去重固化后消除重復記錄,則可以將子查詢轉換為"關聯查詢",即Materialization策略,

如對于查詢:

SELECT * FROM Country 
WHERE Country.code IN (
    SELECT City.Country 
    FROM City 
    WHERE City.Population > 1*1000*1000
)
AND Country.continent='Europe'

在轉換為"關聯查詢"后,按照"關聯查詢"中臨時表是否為"驅動表"可以將Semi-join Materialization策略細分為:

  • Materialization/scan 策略,將臨時表作為"驅動表",遍歷臨時表中每條記錄去另外關聯表中查找匹配記錄,
  • Materialization/lookup 策略,將臨時表作為"被驅動表",遍歷另外的關聯表在臨時表中查詢匹配記錄,

使用Materialization/scan 策略時,MariaDB 查詢計劃為:

MariaDB [world]> explain select * from Country where Country.code IN (select City.Country from City where  City.Population > 7*1000*1000);
+----+--------------+-------------+--------+--------------------+------------+---------+--------------------+------+-----------------------+
| id | select_type  | table       | type   | possible_keys      | key        | key_len | ref                | rows | Extra                 |
+----+--------------+-------------+--------+--------------------+------------+---------+--------------------+------+-----------------------+
|  1 | PRIMARY      | <subquery2> | ALL    | distinct_key       | NULL       | NULL    | NULL               |   15 |                       |
|  1 | PRIMARY      | Country     | eq_ref | PRIMARY            | PRIMARY    | 3       | world.City.Country |    1 |                       |
|  2 | MATERIALIZED | City        | range  | Population,Country | Population | 4       | NULL               |   15 | Using index condition |
+----+--------------+-------------+--------+--------------------+------------+---------+--------------------+------+-----------------------+
3 rows in set (0.01 sec)

使用Materialization/lookup 策略時,MariaDB 查詢計劃為:

MariaDB [world]> explain select * from Country where Country.code IN (select City.Country from City where  City.Population > 1*1000*1000) ;
+----+--------------+-------------+--------+--------------------+--------------+---------+------+------+-----------------------+
| id | select_type  | table       | type   | possible_keys      | key          | key_len | ref  | rows | Extra                 |
+----+--------------+-------------+--------+--------------------+--------------+---------+------+------+-----------------------+
|  1 | PRIMARY      | Country     | ALL    | PRIMARY            | NULL         | NULL    | NULL |  239 |                       |
|  1 | PRIMARY      | <subquery2> | eq_ref | distinct_key       | distinct_key | 3       | func |    1 |                       |
|  2 | MATERIALIZED | City        | range  | Population,Country | Population   | 4       | NULL |  238 | Using index condition |
+----+--------------+-------------+--------+--------------------+--------------+---------+------+------+-----------------------+
3 rows in set (0.00 sec)

Loose Scan策略

在Materialization/scan 策略時,需要先將"子查詢結果集"移除重復記錄并固化到臨時表,再作為驅動表進行關聯查詢,MySQL特性Index Loose Scan能在一次掃描中得跳過重復索引鍵得到"沒有重復記錄的臨時結果集",Loose Scan策略基于Index Loose Scan特性保證關聯查詢不會出現"重復關聯問題",

如對于查詢:

SELECT * FROM Country  
WHERE Country.code IN (
    SELECT country_code FROM Satellite
)

如果Satellite.country_code 存在索引,基于Index Loose Scan特性則能快速獲得"SELECT DISTINCT country_code FROM Satellite"的效果,如圖所示:

使用Loose Scan 策略時,MariaDB 查詢計劃為:

MariaDB [world]> explain select * from Country where Country.code in (select country_code from Satellite);
+----+-------------+-----------+--------+---------------+--------------+---------+------------------------------+------+-------------------------------------+
| id | select_type | table     | type   | possible_keys | key          | key_len | ref                          | rows | Extra                               |
+----+-------------+-----------+--------+---------------+--------------+---------+------------------------------+------+-------------------------------------+
|  1 | PRIMARY     | Satellite | index  | country_code  | country_code | 9       | NULL                         |  932 | Using where; Using index; LooseScan |
|  1 | PRIMARY     | Country   | eq_ref | PRIMARY       | PRIMARY      | 3       | world.Satellite.country_code |    1 | Using index condition               |
+----+-------------+-----------+--------+---------------+--------------+---------+------------------------------+------+-------------------------------------+

Loose Scan 策略和Materialization/scan 策略區別:

  • Materialization/scan 策略:先將子查詢的查詢結果固化去重后,再作為驅動表與外部表進行關聯查詢,查詢使用到臨時表,
  • Loose Scan 策略:在對子查詢的表進行Index Loose Scan操作程序中,直接將遍歷到的記錄與與外部表進行關聯查詢,查詢未使用到臨時表,

Duplicate Weedout策略

當無法根據表結構資訊推算出"子查詢結果集"不存在重復記錄時,如果將子查詢改寫為關聯查詢,則會導致"外表記錄"被關聯匹配多次而產生重復記錄,可以通過將關聯結果集插入到"帶有唯一索引的臨時表"的方式來移除重復記錄,保證最終查詢結果的準確性,

對于查詢:

SELECT * 
FROM Country 
WHERE Country.code IN (
    SELECT City.Country
    FROM City 
    WHERE City.Population > 0.33 * Country.Population 
    AND City.Population > 1*1000*1000
);

可以改寫為:

CREATE tmp_Country LIKE Country;

INSERT IGNORE INTO tmp_Country
SELECT Country.* 
FROM Country
INNER JOIN City
ON Country.code = City.Country
WHERE City.Population > 0.33 * Country.Population 
AND City.Population > 1*1000*1000

SELECT * FROM tmp_Country;

如圖所示:

使用Duplicate Weedout 策略時,MariaDB 查詢計劃為:

explain select * from Country where Country.code IN (select City.Country from City where City.Population > 0.33 * Country.Population and City.Population > 1*1000*1000)\G
*************************** 1. row ***************************
           id: 1
  select_type: PRIMARY
        table: City
         type: range
possible_keys: Population,Country
          key: Population
      key_len: 4
          ref: NULL
         rows: 238
        Extra: Using index condition; Start temporary
*************************** 2. row ***************************
           id: 1
  select_type: PRIMARY
        table: Country
         type: eq_ref
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 3
          ref: world.City.Country
         rows: 1
        Extra: Using where; End temporary
2 rows in set (0.00 sec)

學習總結

First Match策略通過"找到第一條匹配記錄即回傳"的方式來跳過無效子查詢掃描,

除First Match策略外都是子查詢轉換為關聯查詢來優化提升查詢效率,按照不同查詢場景采用不同策略來"避免重復記錄":

  • Table Pullout策略,通過唯一索引和主鍵索引邏輯來確認"子查詢結果集"中重復記錄,
  • Materialization策略,通過臨時表來移除"子查詢結果集"中重復記錄,
  • Loose Scan策略,通過Index Loose Scan特性來跳過"子查詢結果集"中重復記錄,
  • Duplicate Weedout策略,通過臨時表來將移除"關聯查詢結果集"中重復記錄,

參考資料

Semi-join Subquery Optimizations

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/551862.html

標籤:其他

上一篇:實驗小記之Linux上的Oracle11gR2單實體靜默安裝和建庫

下一篇:返回列表

標籤雲
其他(158599) Python(38118) JavaScript(25404) Java(18023) C(15222) 區塊鏈(8262) C#(7972) AI(7469) 爪哇(7425) MySQL(7171) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5871) 数组(5741) R(5409) Linux(5335) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4565) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2432) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1965) Web開發(1951) HtmlCss(1932) python-3.x(1918) 弹簧靴(1913) C++(1912) xml(1889) PostgreSQL(1874) .NETCore(1857) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • Semi-Join Subquery優化策略

    Semi-Join Subquery優化策略 Semi-Join Subquery(半連接子查詢):對應IN或EXISTS子查詢,僅需要檢查"外表記錄"在"子查詢結果集"中是否存在匹配記錄,不需要計算"子查詢結果集"中記錄匹配次數,也不需要回傳"子查詢結果集"中匹配記錄內容 在MariaDB(MyS ......

    uj5u.com 2023-05-07 09:19:40 more
  • 實驗小記之Linux上的Oracle11gR2單實體靜默安裝和建庫

    說明:本文的所有步驟不適用于生產環境,僅用于個人測驗環境的快速部署和學習,下述操作程序在Oracle Linux 7.9上安裝Oracle 11.2.0.4單實體為例。 1 安裝環境檢查 安裝環境的檢查可以參考官方檔案Oracle Database Quick Installation Guide ......

    uj5u.com 2023-05-07 09:19:31 more
  • MySQL如何獲取binlog的開始時間和結束時間

    MySQL資料庫恢復到指定時間點時,我們必須通過MySQL全備+MySQL增量備份(可選)+MySQL的二進制日志(binlog)進行重放來恢復到指定時間點,實際的生產環境中,可能一段時間內生成了多個二進制日志檔案(binlog), MySQL本身不會存盤二進制日志檔案(binlog)的開始時間和結 ......

    uj5u.com 2023-05-07 09:19:25 more
  • GaussDB(DWS)字串處理函式回傳錯誤結果集排查

    摘要:在使用字串處理函式時,有時會出現非預期結果的場景。在排除使用問題后,應該從encoding和資料本身開始排查。 本文分享自華為云社區《GaussDB(DWS)字串處理函式回傳錯誤結果集排查》,作者: -CHEN111- 。 在使用字串處理函式時,有時會出現非預期結果的場景。在排除使用問題 ......

    uj5u.com 2023-05-07 09:19:19 more
  • MySQL備份命令幫助手冊

    借助于 mysqldump 命令可以進行資料庫的備份。 用法: mysqldump [OPTIONS] database [tables] 或:mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...] 或:mysqldump [OPTION ......

    uj5u.com 2023-05-07 09:19:14 more
  • 如何計算真實的資料庫成本

    本文分享自天翼云開發者社區《如何計算真實的資料庫成本》 作者:王****乾 在云計算占主導地位之前,計算資料庫的成本是一個非常簡單的等式:軟體成本+硬體成本=資料庫成本。如果你選擇了一個開源產品,軟體成本可能會消失。雖然云計算已經從根本上改變了我們使用和部署軟體的方式,但仍有太多人在使用這種過時的計 ......

    uj5u.com 2023-05-07 09:19:10 more
  • 一文詳解如何在 ChengYing 中通過產品線部署一鍵提升效率

    在之前的內容當中,我們為大家介紹過 ChengYing 的安裝原理、產品包制作等內容,本篇就延續之前的內容,和大家展開聊聊 ChengYing 產品線部署相關的設計。幫助對「一站式全自動化全生命周期大資料平臺運維管家 ChengYing」感興趣的開發者更好地了解和使用 ChengYing。 產品線部 ......

    uj5u.com 2023-05-07 09:18:56 more
  • MySQL一次大量記憶體消耗的跟蹤

    GreatSQL社區原創內容未經授權不得隨意使用,轉載請聯系小編并注明來源。 GreatSQL是MySQL的國產分支版本,使用上與MySQL一致。 文章來源:GreatSQL社區原創 線上使用MySQL8.0.25的資料庫,通過監控發現資料庫在查詢一個視圖(80張表的union all)時記憶體和cp ......

    uj5u.com 2023-05-07 09:18:42 more
  • 由淺入深學MYSQL之--MySQL分組查詢詳解

    前言 從今天開始本系列文內容就帶各位小伙伴學習資料庫技術。資料庫技術是Java開發中必不可少的一部分知識內容。也是非常重要的技術。本系列教程由淺入深, 全面講解資料庫體系。 非常適合零基礎的小伙伴來學習。 全文大約 【1066】字,不說廢話,只講可以讓你學到技術、明白原理的純干貨!本文帶有豐富案例及 ......

    uj5u.com 2023-05-07 09:18:36 more
  • 如何計算真實的資料庫成本

    本文分享自天翼云開發者社區《如何計算真實的資料庫成本》 作者:王****乾 在云計算占主導地位之前,計算資料庫的成本是一個非常簡單的等式:軟體成本+硬體成本=資料庫成本。如果你選擇了一個開源產品,軟體成本可能會消失。雖然云計算已經從根本上改變了我們使用和部署軟體的方式,但仍有太多人在使用這種過時的計 ......

    uj5u.com 2023-05-07 09:18:16 more