本篇的查詢跑在共用的範例資料庫上：三位顧客佳穎、宗翰、雅文，而只有佳穎下過兩張訂單（101 與 102，金額 300 與 500）。

這一篇處理的是起手式——寫連接時第一個下筆的地方，而它決定了條件之後能放哪裡。SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 處理的是條件寫下之後放哪一邊——那一篇會把配對與成品（關係組完之後得到的那一批列）並排；本篇兩個詞都會用到，而判斷一個條件屬於配對還是成品的完整判定表在那一篇。順序上這一篇在前：先有配對關係，才有條件該放哪裡的問題。

從全部配對縮小的起手式與關聯代數的定義

關聯代數把連接定義成兩個運算的組合：先取笛卡兒積，再用條件選取。所以下面這個寫法是把定義翻成 SQL：

1SELECT 顧客.姓名, 訂單.訂單編號
2FROM 顧客 CROSS JOIN 訂單
3WHERE 訂單.顧客編號 = 顧客.顧客編號;

它讀起來自然是有來由的——每一種配對先擺出來，再挑走不要的。而它是語意層的定義：代數用它說明連接的結果集是什麼，沒有規定寫法要照這個順序展開。引擎也沒有照著做，這一段的計畫與 JOIN ... ON 寫同一個條件逐字相同（SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證）。

這個起手式在內連接底下一直行得通，因為條件放 ON 與放 WHERE 在內連接底下回同一批列。行得通的經驗會累積，直到問題需要保留配不到的列。

從全部配對縮小與寫進 ON 在外連接處的差別

書店要一份名單：每位顧客與他 300 元以上的訂單，而沒有這種訂單的顧客也要列出來。

從全部配對縮小：

1FROM 顧客 CROSS JOIN 訂單
2WHERE 訂單.顧客編號 = 顧客.顧客編號 AND 訂單.金額 >= 300;
3-- 佳穎 101 / 佳穎 102

宗翰與雅文不在名單上。CROSS JOIN 這個關鍵字沒有外連接的形式，所以要讓宗翰與雅文這種沒有訂單的顧客也留在結果裡（這是外連接做的事，下文叫保護：被保護的表裡配不到對象的列照樣留下，另一張表——下文叫補 NULL 的表——的欄位在那一列補上 NULL），這個起手式本身就得換掉。

把 CROSS JOIN 換成 LEFT JOIN 而條件留在原處：

1FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
2WHERE 訂單.金額 >= 300;
3-- 佳穎 101 / 佳穎 102

兩人仍然不在。LEFT 保護下來的那些列右邊全是 NULL，而 WHERE 那一步把它們篩掉了（SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責）。換掉關鍵字補不回那些列，因為要動的是條件的位置。

把配對關係整個寫進 ON：

1FROM 顧客 LEFT JOIN 訂單
2  ON 訂單.顧客編號 = 顧客.顧客編號 AND 訂單.金額 >= 300;
3-- 佳穎 101 / 佳穎 102 / 宗翰 （空）/ 雅文 （空）

三位顧客都在。從全部配對縮小與把配對關係寫進 ON 這兩個起手式，差別在這裡從「寫法偏好」變成「答得出來與答不出來」：從全部配對縮小的起手式把所有條件都放進 WHERE，在成品上篩，而外連接的保護正是在成品那一步被抵銷的。

連接種類的選擇：配不到的列在答案裡有沒有位置

哪兩列該配在一起說完之後，接著要決定的是配不到對象的列怎麼處理。判斷標準是一句話：這些列在答案裡有沒有位置。

有位置就用外連接，而哪一側有位置決定寫 LEFT、RIGHT 還是 FULL；沒有位置就用內連接（JOIN）（外連接那張卡寫三者各保護誰）。「哪些顧客一張單都沒下」這個問題的答案整個在補 NULL 的那幾列上，內連接會讓它無從回答。

還有第三種情形：只問配不配得到，右表的欄位一個都不輸出。那時要的運算是半連接——配起來之後只帶走左邊那一份，右邊只當條件（Semi-join 與 Anti-join）。寫成 JOIN 會讓配得到多列的那些左列重複出現，SQL.8 IN、EXISTS 與 JOIN 寫這三種寫法在列數上的差別，以及選哪一種的判斷標準。

配不到的列要不要保護，這個決定由問題決定，不由現有資料決定。 「翻遍現在的訂單表，每一列都配得到顧客」只證明此刻如此，而查詢要活得比這一批資料久。反過來說，資料保證配得到的時候寫 LEFT 也有代價——它宣告了一個從未發生的情況，下一個讀的人會以為那些列存在（SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證）。要判斷配對有沒有保證，去看約束，而那條保證要真的生效才算數（SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證）。

業務描述對應到查詢的位置：ON、連接種類與 WHERE

「每位顧客與他 300 元以上的訂單，沒有這種訂單的顧客也要列出來」這句話裡有三個決定，各自對應查詢的一個位置。

哪兩列該配在一起。 顧客的那一列與訂單的那一列，靠顧客編號對上，而且只跟 300 元以上的訂單配。這一整句進 ON——「只跟 300 元以上的訂單配」描述的是配對，所以它屬於那裡。

配不到的列要不要。 「沒有這種訂單的顧客也要列出來」說了要，而要保護的是顧客那一側，所以是 LEFT JOIN，左邊放顧客。兩張表的時候這樣判就夠；三張以上時「左邊」是前面幾個連接累積出來的結果，鏈中間放一個 RIGHT 會把前段保護下來的列整批丟掉。累積的判讀，以及同一組資料上四列變一列的實跑，在 SQL.4 鏈式連接的左運算元：累積方式與外連接的保護範圍。

成品裡再篩什麼。 這句話沒有再提條件，所以 WHERE 是空的。業務描述裡沒有針對顧客那一側的限制時，空的 WHERE 是一個合理的結果。

順序反過來走也能檢查已經寫好的查詢：WHERE 裡引用右表欄位的條件，回頭問它描述的是配對，還是成品——多數形態上它描述的是配對，而它待在那裡正在抵銷某個保護。有一個形態剛好相反：WHERE 右表.某欄 IS NULL 挑的正是外連接補上 NULL 的那些列，它描述的是成品，待在 WHERE 是對的位置（SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 有完整的判定表，SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證 用它示範查孤兒訂單）。

只提到被保護的表的條件該放的位置

上一節那句業務描述裡，「哪兩列該配在一起」與「配不到的列要不要」都在問條件與連接種類該怎麼配。而條件提到哪一側，會讓「哪兩列該配在一起」的答案整個不同。換一對表看得清楚。「每張訂單與它的評價，只要三月五日以後下的單」——被保護的是訂單，而「三月五日以後」只提到訂單。條件寫進 ON：

1SELECT 訂單.訂單編號, 訂單.下單日, 評價.星等
2FROM 訂單 LEFT JOIN 評價
3  ON 評價.訂單編號 = 訂單.訂單編號 AND 訂單.下單日 >= '2026-03-05';
4-- 101  2026-03-02  （空）
5-- 102  2026-03-09  （空）

三月二日那張照樣回來，篩選沒有發生——LEFT 的定義是左邊每一列都留著，而 ON 只決定右邊配不配得上，配不上就補 NULL。這個條件改變的是配對：101 本來配得上那筆五星評價，多了這個條件之後整個 ON 對它判假，於是連評價一起丟了。同一個條件改放 WHERE 才回到要的那批列：

1SELECT 訂單.訂單編號, 訂單.下單日, 評價.星等
2FROM 訂單 LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
3WHERE 訂單.下單日 >= '2026-03-05';
4-- 102  2026-03-09  （空）

只提到被保護的表的條件描述的是成品，屬於 WHERE。判斷標準因此要分兩步：先問這個條件提到哪幾張表，只提被保護的表的直接進 WHERE；兩張表都提到、或只提補 NULL 的表的，才問它描述配對還是成品。自連接寫成外連接時也是這樣。自連接指同一張表在一段查詢裡出現兩次、各自扮演一個角色，例如同一張訂單表一次代表較早的訂單、一次代表較晚的訂單；兩次出現裡被保護的那一次，它自己的過濾條件寫進 ON 同樣篩不掉列。配對的兩側是同一張表時，兩次出現要各自有名字才分得開，SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接 用三個引擎的錯誤訊息示範為什麼非取名不可，並把自連接處理的關係分成前後配對、同組比較與層級關係三種形態。放右表的條件另有一組判定，以及它為什麼對左表條件恆為真，在 SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責。

所以空的 WHERE 不是一個要去追求的形狀。上一節那句業務描述留下空的 WHERE，是因為它確實沒有再提條件；把一個只提被保護的表的條件塞進 ON 去換一個空的 WHERE，換來的是一個篩不掉列、還會丟掉本來成立的配對的條件。

SQL 寫成 CROSS JOIN，也可以在 FROM 裡用逗號把兩張表隔開。

條件決定它會不會被展開

代數說連接從積開始，而那是語意層的定義，執行方式由最佳化器按代價選。條件把兩邊綁起來的時候，它用索引或雜湊直接找出配得上的那些列，全部組合一次都沒有被造出來。

條件缺席的時候展開才會發生。一張逐日的觀測表跟自己做沒有條件的 CROSS JOIN：

1CREATE TABLE Weather (id INTEGER PRIMARY KEY, recordDate TEXT, temperature INT);
2WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < 3890)
3INSERT INTO Weather SELECT i, date('2015-01-01', i || ' day'), i % 40 FROM n;
4CREATE UNIQUE INDEX ix ON Weather(recordDate);

1-- SQLite 3.51，Weather 表 3891 列
2SELECT count(*) FROM Weather a CROSS JOIN Weather b;
3-- 15139881
4
5|--SCAN a USING COVERING INDEX ix
6`--SCAN b USING COVERING INDEX ix

15139881 是 3891 的平方。外層每掃一列，內層就把整張表再走一遍，而這一千五百萬對配對在後面的子句拿到資料之前就要先產生出來。這張表加到 13891 列之後，列數變成 3.6 倍而配對數變成 192959881——將近十三倍。成長是平方而非線性，這正是這個運算與其他多出來的列的差別。

要看的是條件把不把兩邊綁起來，而不是用了哪個關鍵字。 CROSS JOIN 加一個等值條件，與 JOIN ... ON 寫同一個條件，對引擎是同一段查詢（SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證）；反過來，JOIN 寫了而 ON 的條件只提到單邊的欄位，展開照樣發生。

與列數膨脹是兩種不同的多

結果比預期多的時候有兩個成因，分辨它們決定要改什麼。

列數膨脹是條件正確而一列配到了多列，於是它被複製那麼多次——多出來的量由資料的重複程度決定，改法是把展開的那一層先收成一列，或改用不展開的寫法。笛卡兒積是條件從一開始就沒有把兩邊綁住——多出來的量由兩張表各自的大小決定，改法是補上那個條件。

分辨的問句落在條件上而非結果上：這個條件把一列綁到對面幾列。 綁到常數量級（幾列、幾十列）是配對條件，多出來的量由重複程度決定，那是膨脹；綁到與表的大小同量級，那個條件篩掉了一些列，而每一列對面掛著的對象數仍然隨表一起長，多出來的量由兩張表的大小決定，那是積。

「有沒有同時引用兩邊」不足以分辨。ON a.v > b.v 同時引用了兩邊，而它把左邊每一列綁到右邊將近一半——v 的值互不相同時，一千列得 499500 對、兩千列得 1999000 對，仍然是平方。低基數的等值鍵同理：ON a.區域 = b.區域 只有幾個區域時，一千列對一千列得五十萬對。

這裡刻意不問「這一列是靠哪個條件配起來的」——JOIN 寫了而 ON 只提單邊欄位的那個形態，讀者答得出「靠那個 ON 條件」而它並沒有把兩邊配起來，問句會把積判成膨脹。

概念位置

笛卡兒積是連接的下限——條件寫得越少，結果越靠近它，而條件寫滿的時候結果落在兩張表配得上的那些列。所以「連接的結果集會不會整個換一個量級」這個問題等於「條件綁住了多少」，與用了 JOIN 還是 CROSS JOIN 無關。而條件綁不綁得住，由它引用到幾個表的出現決定——與那個分辨問句是同一件事。

它在關聯代數裡的位置說明了漏寫連接條件的後果為什麼這麼大：查詢退回它的定義起點，全部組合重新成立。這是結果集大小的整個量級換掉，與逐步變慢是不同的一件事。

往下走

條件正確而列數仍然變多的那一種，在 SQL.6 連接之後的列數與空缺。同一批配對用自連接與 EXISTS 兩種寫法的實測對照，在 SQL.17 查詢的代價。條件只用來判斷存在時結果的上限落在哪裡，在 Semi-join 與 Anti-join（半連接與反連接）。CROSS JOIN 這個關鍵字對讀的人宣告了什麼，在 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證。production 查詢的結果集大小怎麼治理，在 Cardinality Explosion。