子查詢（Subquery）的優化一直以來都是 SQL 查詢優化中的難點之一。關聯子查詢的基本執行方式相似於 Nested-Loop，可是這種執行方式的效率經常低到難以忍受。當數據量稍大時，必須在優化器中對其進行去關聯化（Decoorelation 或 Unnesting），將其改寫爲相似於 Semi-Join 這樣的更高效的算子。安全
前人已經總結出一套完整的方法論，理論上能對任意一個查詢進行去關聯化。本文結合 SQL Server 以及 HyPer 的幾篇經典論文，由淺入深地講解一下這套去關聯化的理論體系。它們兩者所用的方法大同小異，基本思想是想通的。閉包
本文的例子都基於 TPC-H 的表結構，這裏 有一份供你參考。函數
子查詢簡介
子查詢是定義在 SQL 標準中一種語法，它能夠出如今 SQL 的幾乎任何地方，包括 SELECT, FROM, WHERE 等子句中。oop
總的來講，子查詢能夠分爲關聯子查詢（Correlated Subquery）和非關聯子查詢（Non-correlated Subquery）。後者非關聯子查詢是個很簡單的問題，最簡單地，只要先執行它、獲得結果集並物化，再執行外層查詢便可。下面是一個例子：性能
SELECT c_count, count(*) AS custdist FROM ( SELECT c_custkey, count(o_orderkey) AS c_count FROM CUSTOMER LEFT OUTER JOIN ORDERS ON c_custkey = o_custkey AND o_comment NOT LIKE '%pending%deposits%' GROUP BY c_custkey ) c_orders GROUP BY c_count ORDER BY custdist DESC, c_count DESC;
▲ TPCH-13 是一個非關聯子查詢字體
非關聯子查詢不在本文討論範圍之列，除非特別聲明，如下咱們說的子查詢都是指關聯子查詢。優化
關聯子查詢的特別之處在於，其自己是不完整的：它的閉包中包含一些外層查詢提供的參數。顯然，只有知道這些參數才能運行該查詢，因此咱們不能像對待非關聯子查詢那樣。lua
根據產生的數據來分類，子查詢能夠分紅如下幾種：url
標量（Scalar-valued） 子查詢：輸出一個只有一行一列的結果表，這個標量值就是它的結果。若是結果爲空（0 行），則輸出一個 NULL。可是注意，超過 1 行結果是不被容許的，會產生一個運行時異常。spa
標量子查詢能夠出如今任意包含標量的地方，例如 SELECT、WHERE 等子句裏。下面是一個例子：
SELECT c_custkey FROM CUSTOMER WHERE 1000000 < ( SELECT SUM(o_totalprice) FROM ORDERS WHERE o_custkey = c_custkey )
▲ Query 1: 一個出如今 WHERE 子句中的標量子查詢，關聯參數用紅色字體標明瞭
SELECT o_orderkey, ( SELECT c_name FROM CUSTOMER WHERE c_custkey = o_custkey ) AS c_name FROM ORDERS
▲ Query 2: 一個出如今 SELECT 子句中的標量子查詢
存在性檢測（Existential Test） 子查詢：特指 EXISTS 的子查詢，返回一個布爾值。若是出如今 WHERE 中，這就是咱們熟悉的 Semi-Join。固然，它可能出如今任何能夠放布爾值的地方。
SELECT c_custkey FROM CUSTOMER WHERE c_nationkey = 86 AND EXISTS( SELECT * FROM ORDERS WHERE o_custkey = c_custkey )
▲ Query 3: 一個 Semi-Join 的例子
集合比較（Quantified Comparision） 子查詢：特指 IN、SOME、ANY 的查詢，返回一個布爾值，經常使用的形式有：x = SOME(Q) （等價於 x IN Q）或 X <> ALL(Q)（等價於 x NOT IN Q）。同上，它可能出如今任何能夠放布爾值的地方。
SELECT c_name FROM CUSTOMER WHERE c_nationkey <> ALL (SELECT s_nationkey FROM SUPPLIER)
▲ Query 4: 一個集合比較的非關聯子查詢
原始執行計劃
咱們以 Query 1 爲例，直觀地感覺一下，爲何說關聯子查詢的去關聯化是十分必要的。
下面是 Query 1 的未經去關聯化的原始查詢計劃（Relation Tree）。與其餘查詢計劃不同的是，咱們特意畫出了表達式樹（Expression Tree），能夠清晰地看到：子查詢是其實是掛在 Filter 的條件表達式下面的。
img實際執行時，查詢計劃執行器（Executor）在執行到 Filter 時，調用表達式執行器（Evaluator）；因爲這個條件表達式中包含一個標量子查詢，因此 Evaluator 又會調用 Executor 計算標量子查詢的結果。
這種 Executor - Evaluator - Executor 的交替調用十分低效！考慮到 Filter 上可能會有上百萬行數據通過，若是爲每行數據都執行一次子查詢，那查詢執行的總時長顯然是不可接受的。
Apply 算子
上文說到的 Relation - Expression - Relation 這種交替引用不只執行性能堪憂，並且，對於優化器也是個麻煩的存在——咱們的優化規則都是在匹配而且對 Relation 進行變換，而這裏的子查詢卻藏在 Expression 裏，使人無從下手。
爲此，在開始去關聯化以前，咱們引入 Apply 算子：
Apply 算子（也稱做 Correlated Join）接收兩個關係樹的輸入，與通常 Join 不一樣的是，Apply 的 Inner 輸入（圖中是右子樹）是一個帶有參數的關係樹。
Apply 的含義用下圖右半部分的集合表達式定義：對於 Outer Relation RR 中的每一條數據 rr，計算 Inner Relation E(r)E(r)，輸出它們鏈接（Join）起來的結果 r⊗E(r)r⊗E(r)。Apply 的結果是全部這些結果的並集（本文中說的並集指的是 Bag 語義下的並集，也就是 UNION ALL）。
「
Apply 是 SQL Server 的命名，它在 HyPer 的文章中叫作 Correlated Join。它們是徹底等價的。考慮到 SQL Server 的文章發表更早、影響更廣，本文中都沿用它的命名。
根據鏈接方式（⊗⊗）的不一樣，Apply 又有 4 種形式：
- Cross Apply A×A×：這是最基本的形式，行爲剛剛咱們已經描述過了；
- Left Outer Apply ALOJALOJ：即便 E(r)E(r) 爲空，也生成一個 r∘{NULLs}r∘{NULLs}。
- Semi Apply A∃A∃：若是 E(r)E(r) 不爲空則返回 rr，不然丟棄；
- Anti-Semi Apply A∄A∄：若是 E(r)E(r) 爲空則返回 rr，不然丟棄；
咱們用剛剛定義的 Apply 算子來改寫以前的例子：把子查詢從 Expression 內部提取出來。結果以下：
上面的例子中，咱們能夠確定 Scalar Agg 子查詢有且只有一行結果，因此能夠直接轉成 Apply。但某些狀況下，可能沒法確定子查詢必定能返回 0 或 1 行結果（例如，想象一下 Query 2 若是 c_custkey 不是惟一的），爲了確保 SQL 語義，還要在 Apply 右邊加一個 Max1RowMax1Row 算子：
Max1Row(E)=⎧⎩⎨⎪⎪Null,E,error,if |E|=0if |E|=1otherwiseMax1Row(E)={Null,if |E|=0E,if |E|=1error,otherwise
理論上，咱們能夠將全部的子查詢轉換成 Apply 算子，一個通用的方法以下：
- 若是某個算子的表達式中出現了子查詢，咱們就把這個子查詢提取到該算子下面（留下一個子查詢的結果變量），構成一個 ALOJALOJ 算子。若是不止一個子查詢，則會產生多個 ALOJALOJ。必要的時候加上 Max1RowMax1Row 算子。
- 而後應用其餘一些規則，將 ALOJALOJ 轉換成 A×A×、A∃A∃、A∄A∄。例如上面例子中的子查詢結果 XX 被用做 Filter 的過濾條件，NULL 值會被過濾掉，所以能夠安全地轉換成 A×A×。
下面這個例子中，Filter 條件表達式中包含 Q1Q一、Q2Q2 兩個子查詢。轉換以後分別生成了對應的 Apply 算子。其中 Q2Q2 沒法肯定只會生成剛好一條記錄，因此還加上了 Max1RowMax1Row 算子。
基本消除規則
第一組規則是最基本的規則，等式中的 ⊗⊗ 說明它不限制鏈接類型，能夠是 {×,LOJ,∃,∄}{×,LOJ,∃,∄} 中的任意一個。
這兩條規則是很是顯而易見的，翻譯成大白話就是：若是 Apply 的右邊不包含來自左邊的參數，那它就和直接 Join 是等價的。
下面是對 Query 3 應用規則 (2) 的例子：
Project 和 Filter 的去關聯化
第二組規則描述瞭如何處理子查詢中的 Project 和 Filter，其思想能夠用一句話來描述：儘量把 Apply 往下推、把 Apply 下面的算子向上提。
注意這些規則僅處理 Cross Apply 這一種狀況。其餘 3 種 Apply 的變體，理論上均可以轉換成 Cross Apply，暫時咱們只要知道這個事實就能夠了。
你可能會問：一般咱們都是儘量把 Filter、Project 往下推，爲何這裏會反其道而行呢？關鍵在於：Filter、Project 裏面本來包含了帶有關聯變量的表達式，可是把它提到 Apply 上方以後，關聯變量就變成普通變量了！這正是咱們想要的。
咱們稍後就會看到這樣作的巨大收益：當 Apply 被推最下面時，就能夠應用第一組規則，直接把 Apply 變成 Join，也就完成了子查詢去關聯化的優化過程。
下面是對 Query 2 應用規則 (3) 的例子。以後再應用規則 (1)，就完成了去關聯化過程。
Aggregate 的去關聯化
第三組規則描述如何處理子查詢中的 Aggregate（即 Group By）。和上一組同樣，咱們的指導思想仍然是：儘量把 Apply 往下推、把 Apply 下面的算子向上提。
下面等式中，GA,FGA,F 表示帶有 Group By 分組的聚合（Group Agg），其中 AA 表示分組的列，FF 表示聚合函數的列；G1FGF1 表示不帶有分組的聚合（Scalar Agg）。
img這一組規則不像以前那麼簡單直白，咱們先看一個例子找找感受。下面是對 Query 1 運用規則 (9) 的結果：
規則 (9) 在下推 Apply 的同時，還將 ScalarAgg 變成了 GroupAgg，其中，分組列就是 R 的 key，在這裏也就是 CUSTOMER 的主鍵 c_custkey。
「
若是 R 沒有主鍵或惟一鍵，理論上，咱們能夠在 Scan 時生成一個。
爲何變換先後是等價的呢？變換前，咱們是給每一個 R 的行作了一次 ScalarAgg 聚合計算，而後再把聚合的結果合併起來；變換後，咱們先是將全部要聚合的數據準備好（這被稱爲 augment），而後使用 GroupAgg 一次性地作完全部聚合。
這也解釋了爲何咱們要用 ALOJALOJ 而不是本來的 A×A× ：原來的 ScalarAgg 上，即便輸入是空集，也會輸出一個 NULL。若是咱們這裏用 ALOJALOJ，剛好也會獲得同樣的行爲（＊）；反之，若是用 A×A× 就有問題了——沒有對應 ORDERS 的客戶在結果中消失了！
規則 (8) 處理的是 GroupAgg，道理也是同樣的，只不過原來的分組列也要留着。
ScalarAgg 轉換中的細節＊
細心的讀者可能注意到，規則 (9) 右邊產生的聚合函數是 F′F′，多了一個單引號，這暗示它和原來的聚合函數 FF 多是有些不一樣的。那什麼狀況下會不一樣呢？這個話題比較深刻了，不感興趣的同窗能夠跳過。
首先咱們思考下，GroupAgg 以及 ALOJALOJ 的行爲真的和變換前如出一轍嗎？其實否則。舉個反例：
SELECT c_custkey, ( SELECT COUNT(*) FROM ORDERS WHERE o_custkey = c_custkey ) AS count_orders FROM CUSTOMER
設想一下：客戶 Eric 沒有任何訂單，那麼這個查詢應當返回一個 ['Eric', 0] 的行。可是，當咱們應用了規則 (9) 作變換以後，卻獲得了一個 ['Eric', 1] 的值，結果出錯了！
爲什麼會這樣呢？變換以後，咱們是先用 LeftOuterJoin 準備好中間數據（augment），而後用 GroupAgg 作聚合。LeftOuterJoin 爲客戶 Eric 生成了一個 ['Eric', NULL, NULL, ...] 的行；以後的 GroupAgg 中，聚合函數 COUNT(*) 認爲 Eric 這個分組有 1 行數據，因此輸出了 ['Eric', 1]。
下面是個更復雜的例子，也有相似的問題：
SELECT c_custkey FROM CUSTOMER WHERE 200000 < ( SELECT MAX(IF_NULL(o_totalprice, 42)) -- o_totalprice may be NULL FROM ORDERS WHERE o_custkey = c_custkey )
做爲總結，問題的根源在於：F(∅)≠F({NULL})F(∅)≠F({NULL})，這樣的聚合函數 FF 都有這個問題。
變換後的 GroupAgg 沒法區分它看到的 NULL 數據究竟是 OuterJoin 產生的，仍是本來就存在的，有時候，這兩種情形在變換前的 ScalarAgg 中會產生不一樣的結果。
幸運的是，SQL 標準中定義的聚合函數 F(col)F(col) 都是 OK 的——它們都知足 F(∅)=F({NULL})F(∅)=F({NULL})，咱們只要對 FF 稍加變換就能解決這個問題。
- 對於例子一，將 COUNT(*) 替換成一個對非空列（例如主鍵）的 Count 便可，例如：COUNT(o_orderkey)；
- 對於例子二，須要把 MIN(IF_NULL(o_totalprice, 42)) 分紅兩步來作：定義中間變量X，先用 Project 計算 X = IF_NULL(o_totalprice, 42)，再對聚合函數 MIN(X) 進行去關聯化便可。
集合運算的去關聯化
最後一組優化規則用來處理帶有 Union（對應 UNION ALL）、Subtract（對應 EXCEPT ALL） 和 Inner Join 算子的子查詢。再強調一遍，咱們的指導思想是：儘量把 Apply 往下推、把 Apply 下面的算子向上提。
下面的等式中，×× 表示 Cross Join，⋈R.key⋈R.key 表示按照 RR 的 Key 作天然鏈接：r∘e1∘e2r∘e1∘e2 。和以前同樣，咱們假設 RR 存在主鍵或惟一鍵，若是沒有也能夠在 Scan 的時候加上一個。
注意到，這些規則與以前咱們見過的規則有個顯著的不一樣：等式右邊 RR 出現了兩次。這樣一來，要麼咱們把這顆子樹拷貝一份，要麼作成一個 DAG 的執行計劃，總之會麻煩許多。
事實上，這一組規則不多能派上用場。在 [2] 中提到，在 TPC-H 的 Schema 下甚至很難寫出一個帶有 Union All 的、有意義的子查詢。
其餘
有幾個我認爲比較重要的點，用 FAQ 的形式列在下面。
► 是否任意的關聯子查詢均可以被去關聯化？
能夠說是這樣的，在加上少許限定以後，理論上能夠證實：任意的關聯子查詢均可以被去關聯化。
證實方法在 [1]、[3] 中都有說起。以 [1] 中爲例，思路大體是：
- 對於任意的查詢關係樹，首先將關聯子查詢從表達式中提取出來，用 Apply 算子表示；
- 一步步去掉其中非基本關係算子，首先，經過等價變換去掉 Union 和 Subtract；
- 進一步縮小算子集合，去掉 OuterJoin、ALOJALOJ、A∃A∃、A∄A∄；
- 最後，去掉全部的 A×A×，剩下的關係樹僅包含基本的一些關係算子，即完成了去關聯化。
另外一方面，現實世界中用戶使用的子查詢大可能是比較簡單的，本文中描述的這些規則可能已經覆蓋到 99% 的場景。雖然理論上任意子查詢均可以處理，可是實際上，沒有任何一個已知的 DBMS 實現了全部這些變換規則。
► HyPer 和 SQL Server 的作法有什麼異同？
HyPer 的理論覆蓋了更多的去關聯化場景。例如各類 Join 等算子，[3] 中都給出了相應的等價變換規則（做爲例子，下圖是對 Outer Join 的變換）。而在 [1] 中僅僅是證實了這些狀況均可以被規約到可處理的情形（實際上嘛，可想而知，必定是沒有處理的）。
另外一個細節是，HyPer 中還存在這樣一條規則：
其中，D=ΠF(T2)∩A(T1)(T1)D=ΠF(T2)∩A(T1)(T1)，表示對 T1T1 的 Distinct Project 結果（所謂的 _Magic Set_）。直接看等式比較晦澀，看下面的例子就容易理解了：
圖中，在作 Apply 以前，先拿到須要 Apply 的列的 Distinct 值集合，拿這些值作 Apply，以後再用普通的 Join 把 Apply 的結果鏈接上去。
這樣作的好處是：若是被 Apply 的數據存在大量重複，則 Distinct Project 以後須要 Apply 的行數大大減小。這樣一來，即便以後 Apply 沒有被優化掉，迭代執行的代價也會減少很多。
► 本文說的這些變換規則，應該用在 RBO 仍是 CBO 中呢？換句話說，去關聯化後以後的執行計劃必定比去關聯化以前更好嗎？
答案是，不必定。
直觀的看，若是 Apply 的左邊數據量比較少（例如，僅有 1 條數據），那直接帶入 Apply 的右邊計算反而是更好的方式。另外一種狀況是，右邊有合適的索引，這種狀況下，屢次 Apply 的代價也並不是不可接受。
因此把這些規則放進一個 CBO 的優化器是更合適的，優化器根據代價估計選出最優的計劃來。甚至，在某些狀況下，咱們還會自右向左地運用這些等式，作「加關聯化」。
這和用 HashJoin 仍是 NestedLoopJoin 是一樣的道理。事實上，NestedLoopJoin 就是 Apply 的一個特例。若是存在合適的索引，NestedLoopJoin 效率高於 HashJoin 是很常見的事情。