本篇的查詢跑在共用的範例資料庫上：三位顧客佳穎、宗翰、雅文，而只有佳穎下過兩張訂單（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，換來的是一個篩不掉列、還會丟掉本來成立的配對的條件。

本篇要反覆用到這兩件事的名字。配對指關係還在組的那個過程——哪一列跟哪一列湊成一列；成品指關係組完之後得到的那一批列——已經湊好、包含補了 NULL 的那些列在內的整批資料。這兩個詞是本篇為了指認這兩個時刻而取的稱呼，SQL 的標準術語裡沒有它們。

內連接底下，條件寫在 ON 與寫在 WHERE 的結果相同，於是它們看起來可以互換。外連接底下不同，而不同的地方正好是外連接存在的理由。條件擺在哪一邊不影響查詢跑不跑得動，只影響外連接剛保護下來的那些列留不留得住。保護指 LEFT JOIN 把左表配不到對象的列也留在結果裡、右表那幾欄補上 NULL。LEFT JOIN 退化成內連接的名單，來源就是把條件放進 WHERE 這一步。

同一個條件放 ON 與放 WHERE 的結果

書店想要一份名單：全部顧客都要列出來，而評價欄只顯示五星的那些。條件寫進 ON：

1SELECT 顧客.姓名, 評價.星等
2FROM 顧客
3LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5;

回來四列：

1佳穎  5
2佳穎  NULL
3宗翰  NULL
4雅文  NULL

三個顧客都在。佳穎出現兩次，因為她有兩張訂單——第一張有五星評價，第二張沒有評價可配，補 NULL。（一位顧客變成兩列是連接在改變列數，本篇只處理條件決定的留不留，連接怎麼改變列數在 SQL.6 連接之後的列數與空缺。）

同一個星等條件改放 WHERE，其餘不動：

1SELECT 顧客.姓名, 評價.星等
2FROM 顧客
3LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
5WHERE 評價.星等 = 5;
6-- 佳穎  5

宗翰、雅文與佳穎的第二張訂單全部消失，結果與內連接相同。書店要的是全部顧客，所以這一版的答案錯了，而查詢照樣跑、不報錯——這一類錯的共同性質在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法。需求若恰好只要有五星評價的那些，答案就對了，剩下的是文字的問題：LEFT 仍然寫在那裡，照字面讀的人會以為沒配到的顧客都在，那是 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證 的主題。

條件放 ON 與放 WHERE 在外連接底下分岔的原因

LEFT JOIN 的定義是左邊每一列都留著，右邊配不上的補 NULL。條件寫在 ON 裡的時候，它參與的是「配不配得上」這個判斷——宗翰沒有訂單所以配不上任何評價，佳穎的第二張訂單配不上五星評價，照定義都補 NULL 留下來。

條件寫在 WHERE 裡的時候，關係已經組完了，補上的那些 NULL 也已經在裡面。這時候問「星等等於 5」，那些補 NULL 的列答不出 5，於是被篩掉。外連接剛剛保護下來的列，WHERE 這一步又把它們拿掉了。

內連接底下看不出差別，是因為它本來就不保留配不上的列。沒有被保護的列可以被抵銷，所以兩種寫法自然同值。

開頭那段顧客接訂單、再接評價的查詢有三張表，第二個 LEFT JOIN 保護的「左邊」因此是顧客與訂單累積出來的結果；鏈越長，保護的範圍怎麼跟著累積走，是 SQL.4 鏈式連接的左運算元 的題目。

保護存不存活的測試：把補了 NULL 的那一列代進條件

WHERE 只留下判成真的列。而條件的答案有三種——真、假、以及未知：拿 NULL 去跟任何值比較，答案既不是真也不是假（三值邏輯的推導，以及它讓 NOT IN 整段失效的形態，在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

外連接補上的那些列，右表欄位全是 NULL，所以問題變成一句話：這個條件對「什麼都沒有」這一列給出什麼答案。 真的留下，假與未知都被丟掉。

能不能保住不看用了哪個運算子。 IS NOT NULL 看起來與 IS NULL 成對，而在表上的「保護」欄一個是取消、一個是保住，正是因為它對空缺判成假；而 OR 與 COALESCE 這兩種寫法把未知轉成真，保護就留住了。

這張表上的條件全部提到右表，而左表的條件進不了這張表。 補 NULL 的那一列上左表欄位仍然是原本的值，拿它去問什麼都判得出真假，所以保護一定保得住——這個測試對左表條件恆為真，什麼都判別不出來。左表條件實際的問題出在寫進 ON 的時候：它篩不掉左表的任何一列，還會讓本來配得上的那些配對判假。同一個條件 顧客.姓名 <> '佳穎' 放在三個位置：

 1-- 放 WHERE：佳穎被篩掉，宗翰與雅文的保護完好
 2SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
 3FROM 顧客
 4LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 5LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5
 6WHERE 顧客.姓名 <> '佳穎';
 7-- 宗翰  NULL  NULL
 8-- 雅文  NULL  NULL
 9
10-- 放進顧客接訂單的 ON：佳穎與她的兩張訂單判假、配不上，照 LEFT 的定義補 NULL 留下
11SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
12FROM 顧客
13LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號 AND 顧客.姓名 <> '佳穎'
14LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5;
15-- 佳穎  NULL  NULL     三位顧客全回來，佳穎的兩張訂單一起消失
16-- 宗翰  NULL  NULL
17-- 雅文  NULL  NULL
18
19-- 放進接評價的 ON：顧客與訂單在上一步已經配好，佳穎的兩張訂單留著，只是配不到評價
20SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
21FROM 顧客
22LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
23LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5 AND 顧客.姓名 <> '佳穎';
24-- 佳穎  101   NULL
25-- 佳穎  102   NULL
26-- 宗翰  NULL  NULL
27-- 雅文  NULL  NULL

所以左表條件根本不需要走這個測試，它一開始就屬於 WHERE。

這個測試回答的是保護存不存活，不回答條件該放哪一邊。 歸屬要另外問一句：這個條件描述的是配對，還是成品。「只跟五星的評價配」描述的是配對，屬於 ON；「最後的名單裡只要五星那幾列」描述的是成品，屬於 WHERE。兩句話說的是不同的事，而內連接讓這兩種寫法碰巧回同一批列。

多數形態上「保護存不存活」與「條件該放哪一邊」這兩個問題同向——取消了保護的條件，通常正是因為它在描述成品。IS NULL 是這兩個問題答案不同向的那一個形態：它保住了保護，而它要的正好是那些被保護下來的列，所以它同時是「保護存活」與「屬於 WHERE」。下一節寫的就是這個形態。

找沒配到的那些列：IS NULL 條件的歸屬

有時候要的正是「沒配到的那些」。書店想知道哪些顧客一張單都沒下過：

1SELECT 顧客.姓名
2FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3WHERE 訂單.訂單編號 IS NULL;
4-- 宗翰、雅文

這個條件描述的是成品，所以它屬於 WHERE。它與上面那個「退化成內連接」的形態看起來很像——同樣是在 WHERE 裡引用右表欄位——而要的結果剛好相反：這一個挑的正是外連接補上 NULL 的那些列。

分辨這兩種形態的仍然是那個問題：這個條件描述的是配對，還是成品。 「一張單都沒下過」是關於成品的敘述，所以它在 WHERE 是對的位置。

同一題「找沒消費過的顧客」換一個切面，走得到同一個結論。SQL.9 分組鍵的選擇：鍵與一組所代表的對象 從「沒消費的人不會出現在訂單表」這個業務事實走到 NOT EXISTS，並說明在外連接之後分組、再數出零的那種寫法，那個零是查詢自己製造再讀回去的產物。