哪些案例受益於 Reduce、Replicate 和 Redistribute 連接提示？
從 SQL Server 2008 開始的From 子句文件簡要提到了 3 個連接提示及其基本機制：
- 減少
- 複製
- 重新分配
但是，似乎沒有太多關於何時可能需要使用它們的資訊。
看來它們可以與散列、循環和合併一起使用，這些都是為了這個問題的目的而已經理解的。
文件中的相關部分：
對於 SQL 數據倉庫和並行數據倉庫，這些連接提示適用於兩個分佈不兼容列上的 INNER 連接。它們可以通過限制查詢處理期間發生的數據移動量來提高查詢性能。SQL 數據倉庫和並行數據倉庫允許的連接提示如下：
- REDUCE
減少要為連接右側的表移動的行數，以使兩個分佈不兼容的表兼容。REDUCE 提示也稱為半連接提示。
- REPLICATE
使連接左側表的連接列中的值複製到所有節點。右側的表連接到這些列的複製版本。
- REDISTRIBUTE
強制將兩個數據源分佈在 JOIN 子句中指定的列上。對於分佈式表，並行數據倉庫將執行隨機移動。對於復製表，並行數據倉庫將執行修剪移動。要了解這些移動類型，請參閱並行數據倉庫產品文件中“了解查詢計劃”主題中的“DMS 查詢計劃操作”部分。當查詢計劃使用廣播移動來解決分佈不兼容的聯接時，此提示可以提高性能。
一般而言，我們使用連接提示是為了糾正優化器的失敗以辨識更好的查詢計劃。發生這種情況的原因有很多，這些原因大致歸結為優化是一種“足夠好”的方法，受限於尋找計劃的時間預算。
減少
“也稱為半連接提示”。對於半連接，我們只關心另一個表中是否存在任何匹配的行。實際上，這通常是因為查詢具有 EXISTS() 謂詞。如果有一個匹配項或一百萬個結果將是相同的 - 將返回左側（外部）表中的單行。
例如，我們可能想要查詢曾經下過訂單的所有客戶。假設 Customer 是一個小表，但 Order 很大並且分佈在許多節點上。當我們只需要知道每個客戶是否至少存在一行時，將所有數據複製到持有客戶的任何地方都是浪費的。REDUCE 提示提供了這一點。從概念上講，它
select distinct CustomerId from Order在每個持有訂單的節點上執行，速度相對較快。複製
這與 REDUCE 正好相反。在這裡，一個表從其“主”節點整體複製到所有節點，該節點保存來自連接右側表中的數據。
對於這個例子，我們想要所有訂單的總價值，按客戶城市求和。我們只有相對較少的客戶可以舒適地安裝在單個節點上。然而，Orders 表很大並且跨越許多節點。為了滿足查詢，我們必須將 Customer 和 Order 數據放到同一個節點上。複製 Customer 會更有效，因為它更小。REPLICATE 提示強制執行該行為，在每個包含 Order 行的節點上製作 Customer 表的完整副本。
重新分配
這是另一種說明行應如何從其“主”節點移動到另一個節點以便可以評估連接謂詞的方式。這次我們要求伺服器複製數據並根據一些新的分配函式分配該副本，以便複製的行最終會出現在正確的節點上以完成連接。
現在假設我們有一個零售電子商務網站，有很多客戶和大量訂單。客戶按 CustomerId 分配，訂單按 OrderDate 分配。如果我們現在想要
join on Customer.CustomerId = Order.CustomerId最高效的方案可能是複制Order並根據CustomerId重新分發，然後將每個新分區傳遞給對應的節點。這與 REPLICATE 不同，因為整個表被複製到每個節點，而這裡每個節點的數據的一部分被複製到其他節點。處理重新分配的具體方式將取決於目前的分配和基數。