Semi-Join的并行加速
您可以使用Semi-Join半連接優(yōu)化子查詢，減少查詢次數(shù)，提高查詢性能。本文將介紹Semi-Join半連接的基本信息和操作方法。
前提條件
PolarDB集群版本需為PolarDB MySQL版8.0版本且修訂版本滿足以下條件：
8.0.1.0.5 或以上。
8.0.2.2.7 或以上。
如何查看集群版本，請參見查詢版本號。
背景信息
MySQL 5.6.5引入了Semi-Join半連接，當(dāng)外表在內(nèi)表中找到匹配的記錄之后，Semi-Join會返回外表中的記錄。但即使在內(nèi)表中找到多條匹配的記錄，外表也只會返回已經(jīng)存在于外表中的記錄。而對于子查詢，外表的每個符合條件的元組都要執(zhí)行一輪子查詢，效率比較低下。此時使用半連接操作優(yōu)化子查詢，會減少查詢次數(shù)，提高查詢性能。其主要思路是將子查詢上拉到父查詢中，這樣內(nèi)表和外表是并列關(guān)系，外表的每個符合條件的元組，只需要在內(nèi)表中找符合條件的元組即可，所以效率會大大提高。
策略
Semi-Join主要使用了如下策略：
DuplicateWeedout Strategy
該策略創(chuàng)建由
row id組成唯一ID的臨時表，再通過該唯一ID達(dá)到去重目的。
Materialization Strategy
該策略將
nested tables物化到臨時表中，再通過查找物化表或者遍歷物化表查找外表的方法達(dá)到去重目的。
Firstmatch Strategy
該策略采用順序查找表的方式，找到第一個匹配的記錄后立即跳轉(zhuǎn)到最后一個外表，并對外表的下一條記錄執(zhí)行JOIN操作，從而達(dá)到去重的目的。
LooseScan Strategy
該策略對內(nèi)表基于索引（Index）進(jìn)行分組，分組后與外表執(zhí)行JOIN（進(jìn)行Condition的匹配）操作，如果存在匹配的記錄，則提取外表的記錄，內(nèi)表選取下一個分組繼續(xù)進(jìn)行計算，從而達(dá)到去重目的。
語法
Semi-Join通常使用IN或EXISTS作為連接條件。
IN
SELECT * FROM Employee WHERE DeptName IN ( SELECT DeptName FROM Dept )EXISTS
SELECT * FROM Employee WHERE EXISTS ( SELECT 1 FROM Dept WHERE Employee.DeptName = Dept.DeptName )
并行Semi-Join性能提升
對于選擇Semi-Join策略的查詢，PolarDB對Semi-Join所有策略實現(xiàn)了并行加速。通過拆分Semi-Join的任務(wù)，多線程模型并行運行任務(wù)集，強化去重能力，使查詢性能得到了顯著的提升。在PolarDB 8.0.2.2.7后支持對物化策略（Semi-Join Materialization）的多階段并行查詢，進(jìn)一步提升了Semi-Join的查詢性能，以Q20為例進(jìn)行說明。
SELECT
s_name,
s_address
FROM
supplier,
nation
WHERE
s_suppkey IN
(
SELECT
ps_suppkey
FROM
partsupp
WHERE
ps_partkey IN
(
SELECT
p_partkey
FROM
part
WHERE
p_name LIKE '[COLOR]%'
)
AND ps_availqty > (
SELECT
0.5 * SUM(l_quantity)
FROM
lineitem
WHERE
l_partkey = ps_partkey
AND l_suppkey = ps_suppkey
AND l_shipdate >= date('[DATE]')
AND l_shipdate < date('[DATE]') + interval '1' year )
)
AND s_nationkey = n_nationkey
AND n_name = '[NATION]'
ORDER BY
s_name;本文例子中，子查詢和外層查詢都以并行度（DOP）為32并行執(zhí)行，子查詢首先并行生成物化表，之后外層查詢也并行的進(jìn)行后續(xù)處理，充分發(fā)揮CPU的處理能力，將查詢并行能力最大化。下文展示了在標(biāo)準(zhǔn)TPC-H中，SCALE為100 GB的數(shù)據(jù)量熱數(shù)據(jù)場景下，開啟并行后多階段的并行處理能力。
并行的執(zhí)行計劃如下：
-> Sort: <temporary>.s_name (cost=5014616.15 rows=100942)
-> Stream results
-> Nested loop inner join (cost=127689.96 rows=100942)
-> Gather (slice: 2; workers: 64; nodes: 2) (cost=6187.68 rows=100928)
-> Nested loop inner join (cost=1052.43 rows=1577)
-> Filter: (nation.N_NAME = 'KENYA') (cost=2.29 rows=3)
-> Table scan on nation (cost=2.29 rows=25)
-> Parallel index lookup on supplier using SUPPLIER_FK1 (S_NATIONKEY=nation.N_NATIONKEY), with index condition: (supplier.S_SUPPKEY is not null), with parallel partitions: 863 (cost=381.79 rows=631)
-> Single-row index lookup on <subquery2> using <auto_distinct_key> (ps_suppkey=supplier.S_SUPPKEY)
-> Materialize with deduplication
-> Gather (slice: 1; workers: 64; nodes: 2) (cost=487376.70 rows=8142336)
-> Nested loop inner join (cost=73888.70 rows=127224)
-> Filter: (part.P_NAME like 'lime%') (cost=31271.54 rows=33159)
-> Parallel table scan on part, with parallel partitions: 6244 (cost=31271.54 rows=298459)
-> Filter: (partsupp.PS_AVAILQTY > (select #4)) (cost=0.94 rows=4)
-> Index lookup on partsupp using PRIMARY (PS_PARTKEY=part.P_PARTKEY) (cost=0.94 rows=4)
-> Select #4 (subquery in condition; dependent)
-> Aggregate: sum(lineitem.L_QUANTITY)
-> Filter: ((lineitem.L_SHIPDATE >= DATE'1994-01-01') and (lineitem.L_SHIPDATE < <cache>((DATE'1994-01-01' + interval '1' year)))) (cost=4.05 rows=1)
-> Index lookup on lineitem using LINEITEM_FK2 (L_PARTKEY=partsupp.PS_PARTKEY, L_SUPPKEY=partsupp.PS_SUPPKEY) (cost=4.05 rows=7)在標(biāo)準(zhǔn)TPC-H 100 GB的數(shù)據(jù)量，熱數(shù)據(jù)場景下，串行的執(zhí)行時間：
多機并行開啟情況下的執(zhí)行時間：
可以看到執(zhí)行時間從43.52秒減少到了2.29秒，性能提升19倍。