JOIN是SQL中用于多表關聯的運算，無論從程序員編寫還是數據庫實現角度來看，JOIN都是SQL中最難的運算。

其實，SQL對JOIN的定義非常簡單，就是對兩個集合(表)做笛卡爾積后再按某種條件過濾，寫出來的語法也就是A JOIN B ON ...的形式。原則上，笛卡爾積后的結果集應當是以兩集合成員構成的二元組為成員，不過由于SQL中的集合成員總是有字段的記錄，而且也不支持泛型數據類型來描述成員為記錄的二元組，所以就簡單地把結果集處理成由兩表記錄的字段合并后構成的新記錄集合。這也是JOIN一詞在英語中的愿意，并沒有乘法(笛卡爾積)的意思。把結果集理解成二元組還是字段合并的記錄，都不會影響本文的討論。

一

JOIN定義中并沒有規定過濾條件的形式。理論上，只要目標結果集是兩源集笛卡爾積的子集，都可以理解為JOIN運算。比如，我們可以計算 A JOIN B ON A

不過，有經驗的程序員都知道，現實中絕大多數JOIN都是等值JOIN，即過濾條件是一個或多個相等關系(多個之間是AND關系)，語法形如A JOIN B ON A.ai=B.bi AND ...，其中ai和bi分別是A和B的字段。而前述例子中ON A

根據對空值的處理規則，等值JOIN還可以衍生出LEFT JOIN和FULL JOIN，而且一般會被分成一對一、一對多、多對多等幾種情況。這些常規術語在所有的SQL教科書都有，這里就不再贅述了。

二

我們來考察下面三種等值JOIN：

1. 外鍵表

表A的某些字段與表B的主鍵關聯(所謂關聯，是指JOIN的過濾條件即由這些對應字段相等構成)。A表稱為事實表，B表稱為維表。A表中與B表主鍵關聯的字段稱為A指向B的外鍵，B也稱為A的外鍵表。外鍵表是多對一的關系，且只有JOIN和LEFT JOIN，一般不會用到FULL JOIN。

典型例子：帳戶交易記錄和帳戶基本信息。

2. 同維表

表A的主鍵與表B的主鍵關聯，A和B互稱為同維表。同維表是一對一的關系，JOIN、LEFT JOIN和FULL JOIN的情況都會有。

典型例子：員工表和銷售員表。

3. 主子表

表A的主鍵與表B的部分主鍵關聯，A稱為主表，B稱為子表。主子表是一對多的關系，只有JOIN和LEFT JOIN，不會有FULL JOIN。

典型例子：訂單和訂單明細。

三

這里說的主鍵是指邏輯上的主鍵，也就是在表中取值***的字段(組)，一個表上可能有多個字段(組)都取值***(并不常見)，可以認為都是主鍵。不是一定是在物理表上建立的那個主鍵。

在SQL的概念體系中并不區分外鍵表和主子表，多對一和一對多從SQL的觀點看來只是關聯方向不同，本質上是一回事。確實，訂單也可以理解成訂單明細的外鍵表。但是，我們在這里要把它們區分開，將來在簡化語法和性能優化時將使用不同的手段。

我們說，這三種JOIN已經涵蓋了絕大多數等值JOIN的情況，甚至可以說幾乎全部有業務意義的等值JOIN都屬于這三類，把等值JOIN限定在這三種情況之中，幾乎不會減少其適應范圍。

四

仔細考察這三種JOIN，我們發現所有關聯都涉及主鍵，沒有多對多的情況，可以不考慮這種情況嗎?

是的!多對多的等值JOIN幾乎沒有業務意義。

如果JOIN兩個表時的關聯字段沒有涉及到任何主鍵，那就會發生多對多的情況，而這種情況幾乎一定還會有一個規模更大的表把這兩個表作為維表關聯起來。比如學生表和科目表在JOIN時，會有個成績表以學生表和科目表作為維表，單純只有學生表和科目表的JOIN沒有業務意義了。

當寫SQL時發現多對多的情況，那大概率是這個語句寫錯了!或者數據有問題!這條法則用于排除JOIN錯誤很有效。

不過，我們一直在說“幾乎”，并沒有用完全肯定的說法，也就是說，多對多在非常罕見的情況下也會業務意義。可舉一例，用SQL實現矩陣乘法時會發生多對多的等值JOIN，具體寫法讀者可以自行補充。

五

笛卡爾積再過濾這種JOIN定義，確實非常簡單，而且簡單的內涵將得到更大的外延，可以把多對多等值JOIN甚至非等值JOIN等都包括進來。但是，過于簡單的內涵無法充分體現出最常見等值JOIN的運算特征。這會導致編寫代碼和實現運算時就不能利用這些特征，在運算較為復雜時(涉及關聯表較多以及有嵌套的情況)，無論是書寫還是優化都非常困難。而充分利用這些特征后，我們就能創造更簡單的書寫形式并獲得更高效率的運算性能，我們將在以后的文章中逐步說明。

與其為了把罕見情況也被包括進來而把運算定義為更通用的形式，還不如把這些情況定義成另一種運算更為合理。