MySQL查詢語句中的IN 和Exists 對比分析

背景介紹

最近在寫SQL語句時，對選擇IN 仍是Exists 猶豫不決，因而把兩種方法的SQL都寫出來對比一下執行效率，發現IN的查詢效率比Exists高了不少，因而想固然的認爲IN的效率比Exists好，但本着尋根究底的原則，我想知道這個結論是否適用全部場景，以及爲何會出現這個結果。
網上查了一下相關資料，大致能夠概括爲：外部表小，內部表大時，適用Exists；外部表大，內部表小時，適用IN。那我就困惑了，由於個人SQL語句裏面，外表只有1W級別的數據，內表有30W級別的數據，按網上的說法應該是Exists的效率會比IN高的，但個人結果恰好相反！！
「沒有調查就沒有發言權」！因而我開始研究IN 和Exists的實際執行過程，從實踐的角度出發，在根本上去尋找緣由，因而有了這篇博文分享。

實驗數據

個人實驗數據包括兩張表：t_author表 和 t_poetry表。
對應表的數據量：
t_author表，13355條記錄；
t_poetry表，289917條記錄。
對應的表結構以下：
CREATE TABLE t_poetry (
id bigint(20) NOT NULL AUTO_INCREMENT,
poetry_id bigint(20) NOT NULL COMMENT '詩詞id',
poetry_name varchar(200) NOT NULL COMMENT '詩詞名稱',
<font color=red> author_id bigint(20) NOT NULL COMMENT '做者id'</font>
PRIMARY KEY (id),
<font color=red>
UNIQUE KEY pid_idx (poetry_id) USING BTREE,
KEY aid_idx (author_id) USING BTREE</font>
) ENGINE=InnoDB AUTO_INCREMENT=291270 DEFAULT CHARSET=utf8mb4

CREATE TABLE t_author (
id int(15) NOT NULL AUTO_INCREMENT,
<font color=red> author_id bigint(20) NOT NULL,</font>
author_name varchar(32) NOT NULL,
dynasty varchar(16) NOT NULL,
poetry_num int(8) NOT NULL DEFAULT '0'
PRIMARY KEY (id),
<font color=red>UNIQUE KEY authorid_idx (author_id) USING BTREE</font>
) ENGINE=InnoDB AUTO_INCREMENT=13339 DEFAULT CHARSET=utf8mb4

執行計劃分析

IN 執行過程

sql示例：select * from tabA where tabA.x in (select x from tabB where y>0 );
其執行計劃：
（1）執行tabB表的子查詢，獲得結果集B，可使用到tabB表的索引y；
（2）執行tabA表的查詢，查詢條件是tabA.x在結果集B裏面，可使用到tabA表的索引x。

Exists執行過程

sql示例：select from tabA where exists (select from tabB where y>0);
其執行計劃：
（1）先將tabA表全部記錄取到。
（2）逐行鍼對tabA表的記錄，去關聯tabB表，判斷tabB表的子查詢是否有返回數據，5.5以後的版本使用Block Nested Loop(Block 嵌套循環)。
（3）若是子查詢有返回數據，則將tabA當前記錄返回到結果集。
tabA至關於取全表數據遍歷，tabB可使用到索引。

實驗過程

實驗針對相同結果集的IN和Exists 的SQL語句進行分析。
包含IN的SQL語句：
select from t_author ta where author_id in
(select author_id from t_poetry tp where tp.poetry_id>3650 );
包含Exists的SQL語句：
select from t_author ta where exists
(select * from t_poetry tp where tp.poetry_id>3650 and tp.author_id=ta.author_id);

第一次實驗

數據狀況

t_author表，13355條記錄；t_poetry表，子查詢篩選結果集 where poetry_id>293650 ，121條記錄；

執行結果

使用exists耗時0.94S， 使用in耗時0.03S，<font color=red>IN 效率高於Exists</font>。

緣由分析

對t_poetry表的子查詢結果集很小，且二者在t_poetry表都能使用索引，對t_poetry子查詢的消耗基本一致。二者區別在於，使用 in 時，t_author表能使用索引:

使用exists時，t_author表全表掃描:

在子查詢結果集較小時，查詢耗時主要表如今對t_author表的遍歷上。

第二次實驗

數據狀況

t_author表，13355條記錄；t_poetry表，子查詢篩選結果集 where poetry_id>3650 ，287838條記錄；

執行時間

使用exists耗時0.12S， 使用in耗時0.48S，<font color=red>Exists IN</font>。

緣由分析

二者的索引使用狀況跟第一次實驗是一致的，惟一區別是子查詢篩選結果集的大小不一樣，但實驗結果已經跟第一次的不一樣了。這種狀況下子查詢結果集很大，咱們看看mysql的查詢計劃：
使用in時，因爲子查詢結果集很大，對t_author和t_poetry表都接近於全表掃描，此時對t_author表的遍歷耗時差別對總體效率影響能夠忽略，執行計劃裏多了一行<auto_key>，在接近全表掃描的狀況下，mysql優化器選擇了auto_key來遍歷t_author表：

使用exists時，數據量的變化沒有帶來執行計劃的改變，但因爲子查詢結果集很大，5.5之後的MySQL版本在exists匹配查詢結果時使用的是Block Nested-Loop（Block嵌套循環，引入join buffer，相似於緩存功能）開始對查詢效率產生顯著影響，尤爲針對<font color=red>子查詢結果集很大</font>的狀況下能顯著改善查詢匹配效率：

實驗結論

根據上述兩個實驗及實驗結果，咱們能夠較清晰的理解IN 和Exists的執行過程，並概括出IN 和Exists的適用場景：

• IN查詢在內部表和外部表上均可以使用到索引；
• Exists查詢僅在內部表上可使用到索引；
• 當子查詢結果集很大，而外部表較小的時候，Exists的Block Nested Loop(Block 嵌套循環)的做用開始顯現，並彌補外部表沒法用到索引的缺陷，查詢效率會優於IN。
• 當子查詢結果集較小，而外部表很大的時候，Exists的Block嵌套循環優化效果不明顯，IN 的外表索引優點佔主要做用，此時IN的查詢效率會優於Exists。
• 網上的說法不許確。其實「表的規模」不是看內部表和外部表，而是外部表和子查詢結果集。
• 最後一點，也是最重要的一點：世間沒有絕對的真理，掌握事物的本質，針對不一樣的場景進行實踐驗證纔是最可靠有效的方法。

實驗過程當中發現的問題補充

僅對不一樣數據集狀況下的上述exists語句分析時發現，數據集越大，消耗的時間反而變小，以爲很奇怪。具體查詢條件爲：where tp.poetry_id>3650，耗時0.13Swhere tp.poetry_id>293650，耗時0.46S可能緣由：條件值大，查詢越靠後，須要遍歷的記錄越多，形成最終消耗越多的時間。這個解釋有待進一步驗證後再補充。