現代 RDBMS 中兩個或多個邏輯關係/表的物理共集群

優化搜尋查詢的一種可能方法是（a）將保留與不同關係/表對應的數據的記錄儲存在（b）相同文件→相同頁面上。這樣，可以更快地執行連接。

我用Google搜尋了“共同分群”，結果出人意料地很少。例如，我在 MySQL 上一無所獲。有跡象表明甲骨文在 10 年前就提供了它。聯合集群仍然是優化的有效選擇嗎？

例如，您有兩個關係/表：

• Employee (id, name, age, did)
• Department (did, location)

您優化的典型查詢可能如下所示：

SELECT E.name, 
      E.age 
 FROM Employee E, 
      Department D 
WHERE E.age = 25 
  AND E.did = D.did;

如果您有 1,000,000 名員工並且他們都在 25 到 27 之間，那麼最好的連接方法可能是排序合併連接或雜湊連接 - 兩者都需要多次掃描。

現在，如果您在同一頁面上儲存多個關係/表的元組/行，您可以使用一種物理結構，將具有某個特定的部門與did具有相同的員工一起儲存did。請注意，這種連接需要更少的 IO。

聯合集群仍然是優化的有效選擇嗎？

當然，如果您的 DBMS 提供它，它是一個有效的優化選項。正如 David Browne 在評論中提到的那樣，只有 Oracle 這樣做（在某種程度上，它告訴你這個特性有多實用）。

正如您所指出的，它在非常有限的場景中很有用，但不利於更廣泛的查詢。在可能從表共集群中受益的情況下，您可以採用替代優化技術，例如物化（索引）視圖或按列組織的表，它們提供類似的性能優勢，同時更廣泛可用。

還要考慮到今天 SSD 儲存的普遍使用、數據庫伺服器上大量廉價 RAM 以及更好的查詢優化器，以可能的負面影響和額外的數據庫維護成本為代價，降低了物理 I/O 邊際減少的價值。

TLDR：不要打擾。

引用自：https://dba.stackexchange.com/questions/247067