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

書店有三位顧客——佳穎下過兩張訂單、宗翰與雅文一張都沒下。要一份「每位顧客與他的訂單」的名單，用內連接得到：

1佳穎  101
2佳穎  102

宗翰與雅文不在名單上。他們沒有訂單可以配對，於是內連接把他們整個丟掉了。換成 LEFT JOIN：

1佳穎  101
2佳穎  102
3宗翰  NULL
4雅文  NULL

這就是「保護」的意思：左邊那張表的每一列都留著，右邊配不上的欄位補 NULL。而「哪些顧客一張單都沒下」這個問題，答案正是那兩列補 NULL 的——內連接會讓它無從回答。

三種寫法差在保護哪一側：LEFT 保護左運算元，RIGHT 保護右運算元，FULL 兩側都保護。

概念位置

外連接產出的仍然是一個 relation，所以它可以繼續當下一個連接的輸入，而 query optimizer 在特定條件下可以把它降級成內連接——前提是查詢的其他部分已經讓補 NULL 的那些列不可能出現在結果裡。

補上的 NULL 是這個機制的產物，與資料裡本來就有的空值來源不同。這一點決定了後續怎麼判斷：IS NULL 問的可能是「這一列沒配到」，也可能是「配到了而那個欄位本來就空」。

可觀察訊號與例子

保護會被 WHERE 抵銷。上面那個 LEFT JOIN 加上 WHERE 訂單.金額 > 100 之後，宗翰與雅文那兩列的金額是 NULL、答不出「大於 100」，於是被篩掉，結果與內連接相同。

外連接寫了卻拿到內連接的結果，多半就是這件事：WHERE 裡引用了右表的欄位。判斷保不保得住的方法是把補 NULL 的那一列代進條件裡：判成真才留得下來。IS NULL 判成真所以保住，IS NOT NULL 判成假所以取消——兩者看起來成對而落在相反的一側。而反查「沒配到的那些」要挑一個不可為空的欄位（通常是連接鍵）來問 IS NULL，用可為空的欄位會把「配到了而那個欄位本來就空」的列一起挑進來。

設計責任

要在保留左側全部列的前提下限制右側的配對範圍，條件寫進 ON；要從成品裡篩，條件寫進 WHERE。兩者在內連接底下同值，所以這個差別只在外連接現形。

鏈式查詢裡混用 LEFT 與 RIGHT 會讓保護的方向中途反轉。RIGHT 的右運算元通常只是一張表，而左運算元是前面累積出來的全部，所以保護範圍與多數人的本意相反。把需要保護的表移到最前面、其餘一律 LEFT，方向就一致了。

左運算元會累積這件事決定三件事：每個 ON 引用得到哪些欄位、每個 LEFT 保護的是哪些列（保護指 LEFT 左邊配不到對象的列也留在結果裡、右邊那幾欄補 NULL）、以及在鏈中間換成 RIGHT 會發生什麼。

累積這件事在只有一個 JOIN 的查詢裡不現形，從第二個開始才有分量：某個 LEFT 保護了哪些列，取決於它上面累積出來的是什麼。

左運算元的累積與判讀方法

書店的顧客有三位——佳穎下過兩張單，宗翰與雅文一張都沒有，而兩張單裡只有一張被評價過。要一份完整名單：每位顧客連同他的訂單與那張訂單的評價，沒下單的顧客與沒被評價的訂單也要出現。三張表往下接：

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

回來四列：

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

第二個 LEFT JOIN 的左邊是顧客與訂單併出來的結果，包含宗翰與雅文那兩列補 NULL 的訂單欄。問第二個 LEFT JOIN「左邊是哪一張表」得不到答案，因為左邊已經不是一張表。判讀的作法回到查詢的文字：在要判讀的那個 JOIN 所在的那一行上方畫一條橫線，橫線以上寫到的表合起來是左運算元，那一行自己掛的那張表是右運算元。

由此得到兩個可以直接用的結論。第二個 ON 寫得出顧客表的欄位，因為顧客在左運算元裡面。第二個 JOIN 若換成 INNER，砍掉的是橫線以上那四列裡配不到評價的三列，而不只是「沒有評價的訂單」——宗翰與雅文會一起消失，儘管他們與評價這張表毫無關係：

1SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
2FROM 顧客
3LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號   -- 橫線以上：佳穎 101、佳穎 102、宗翰、雅文四列
4JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;       -- 內連接：四列裡配不到評價的三列一起砍掉
5-- 佳穎  101  5

他們那兩列訂單欄裡的 NULL 是連接的產物，不是資料裡本來的空值，而後續對這欄做的計數與比較分不出這件事。LEFT 保護左側、RIGHT 保護右側、FULL 兩側都保護，這三種方向與這些 NULL 的來源定義在 Outer Join（外連接）；這些 NULL 怎麼讓聚合算錯、為什麼不能用等號比，由 SQL.6 連接之後的列數與空缺 接手。

鏈中間的 RIGHT JOIN 保護的對象

把最後一個 LEFT 換成 RIGHT，其餘一個字不動：

1FROM 顧客
2LEFT  JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3RIGHT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號

結果從四列變成一列，只剩 佳穎 101 5。

RIGHT 保護的是右運算元，而右運算元是評價這一張表。左運算元——顧客與訂單累積出來的那四列——整批降級成可選的，配不上評價的就丟掉。宗翰、雅文、以及佳穎那張沒被評價的訂單，全部消失。

語意上這等於宣告「每一則評價都要留著，而顧客與訂單可有可無」。 書店大概不會想問這個問題。它幾乎不會是任何人在鏈尾接上評價那個 JOIN 時想表達的事，而它讀起來只像是把 LEFT 打成了 RIGHT。

只用 LEFT JOIN 的鏈：保護方向的判讀與 FULL JOIN 的例外

不用 RIGHT 的話，鏈裡每個 JOIN 都是同一個方向：要保護的那張表寫在最上面，往下一行一行掛可選的表。要判斷查詢裡任何一個 JOIN 保護了什麼，在它那一行上方畫橫線就夠了。

真正需要保護的表放到 FROM 之後、寫成鏈最上面那一張就好。

兩張表都需要保護的時候這個做法不適用，那時要的是 FULL JOIN——它兩側都保護，配不上的兩邊各補一次 NULL。鏈裡出現它，「最上面那張表受保護」這個規律就不成立了，判讀要回到逐個連接看保護的方向。要「每一則評價都在、順便看得到它屬於誰」，就從評價開始往下掛訂單與顧客：

1SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
2FROM 評價
3LEFT JOIN 訂單 ON 訂單.訂單編號 = 評價.訂單編號
4LEFT JOIN 顧客 ON 顧客.顧客編號 = 訂單.顧客編號;
5-- 佳穎  101  5，與鏈尾換成 RIGHT 的那段查詢是同一個列集合

這段查詢的每個 JOIN 都是 LEFT，鏈的方向沒有中途反轉。

書寫的左右與引擎的執行順序

左右是書寫位置決定的語意，與引擎實際先處理誰無關。同一個連接寫成 FROM 訂單 JOIN 顧客 與 FROM 顧客 JOIN 訂單，在跑過 ANALYZE 的資料庫上，SQLite 兩次給出完全相同的 query plan——它掃二十萬列的訂單、對五十列的顧客做查找，與誰寫在前面無關。沒有統計時它會改照文字順序走，而那只是它沒有別的資訊時的退路——SQL.1 宣告式的紅利與代價 對照有無統計資訊時引擎怎麼選計畫。

左右決定哪一側的列被保護，執行順序決定誰先被掃，兩者互不相干。 混用這兩個直覺會讓人以為調換書寫順序可以調效能，或以為從查詢文字看得出引擎的動作。

WHERE 引用鏈尾那張表時被撤掉保護的列

WHERE 篩的是整條鏈累積完的那四列。條件引用鏈尾評價表的欄位時，佳穎的 102、宗翰與雅文那三列的評價欄是補出來的 NULL，一起被篩掉——宗翰與雅文跟評價表毫無關係，他們的保護是第一個 LEFT JOIN 給的：

1SELECT 顧客.姓名, 訂單.訂單編號, 評價.星等
2FROM 顧客
3LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
5WHERE 評價.星等 = 5;   -- 補出來的 NULL 判成未知，那三列被篩掉
6-- 佳穎  101  5

在這份資料上，消失的正好是把第二個 JOIN 換成 INNER 時消失的同一批列。所以判讀一個 WHERE 條件撤掉了誰，同樣回到累積：它引用的表掛在鏈的哪一行，那一行以上累積進來、在那張表上配不到的列都在它的射程裡。條件對 NULL 判成什麼決定撤不撤得掉，哪幾種條件形態保得住保護，在 SQL.5 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，並說明在外連接之後分組、再數出零的那種寫法，那個零是查詢自己製造再讀回去的產物。

列數變多與多出空缺各自帶來一類錯誤，兩類都不報錯。列數變多帶來的錯誤本篇叫列數膨脹：聚合數的是連接之後的列，回了比實際大的數字。空缺帶來的錯誤本篇叫比較 NULL 的錯誤：拿 NULL 做比較，答案是未知而不是真或假，WHERE 裡的等號與 NOT IN 因此回了零列，NOT EXISTS 子查詢裡的不等號則多留了一列。

列數膨脹與各類聚合的修法

這一節反覆數的是列，也就是橫向的一筆資料——三張訂單就是三列，欄位有幾個與這件事無關。

書店的訂單表有兩列，而共用資料裡兩張訂單只有 101 被評價過，所以接上評價表之後仍是兩列。替 101 再加一則評價，列數就變成三：

1SELECT count(*) FROM 訂單 LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
2-- 共用資料：2
3
4INSERT INTO 評價 VALUES (9002, 101, 3);
5
6SELECT count(*) FROM 訂單 LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
7-- 替 101 再加一則評價之後：3

訂單一張都沒有增加，而連接後的關係多了一列。原因是配對是逐列做的：訂單 101 配得上兩則評價，於是它在結果裡出現兩次，兩次帶著不同的評價。

後續的聚合算的是這個新關係的列，不是訂單表的列。 所以數佳穎有幾張訂單，直接數會得到錯的答案：

1SELECT 顧客.姓名, count(*) AS 看起來的訂單數,
2       count(DISTINCT 訂單.訂單編號) AS 實際訂單數
3FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
5GROUP BY 顧客.姓名;
6-- 佳穎 | 3 | 2

佳穎實際有兩張訂單，而 count(*) 回報三。SQLite、DuckDB 與 PostgreSQL 的答案都是這一組。

列數膨脹最難察覺的地方在於數字看起來合理。count(*) 的三比實際訂單數的二只多一，而且它會隨著評價增加而慢慢變大——沒有任何一刻它會大到讓人起疑。

判斷方法是問這個聚合要數的是哪一個層次的單位——訂單、還是連接之後的列。決定那個層次的是分組鍵（選鍵的判斷標準在 SQL.9 分組鍵的選擇：鍵與一組所代表的對象），而把單位拉回來的做法依聚合的性質分三種。

數個數的用 count(DISTINCT 訂單編號)，計數的單位就回到訂單。

加總的不能用 DISTINCT。直接加總時同一張訂單的金額被加了兩次，而 sum(DISTINCT 金額) 去掉的是重複的值、不是重複的訂單，兩張金額剛好相同的訂單會被它當成同一筆而少加一次。加總的解法是讓展開的那一層在接上來之前就已經收成一列：

 1-- 直接連接再加總：101 配到兩則評價，300 被加了兩次
 2SELECT sum(訂單.金額) FROM 訂單 LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
 3-- 1100
 4
 5-- 括號裡那一段先把每張訂單的評價收成一列，接上來之後每張訂單在結果裡只有一列
 6SELECT 訂單.訂單編號, 訂單.金額, 評價數
 7FROM 訂單
 8LEFT JOIN (SELECT 訂單編號, count(*) AS 評價數 FROM 評價 GROUP BY 訂單編號) AS 評價統計
 9  ON 評價統計.訂單編號 = 訂單.訂單編號;
10-- 101 | 300 | 2
11-- 102 | 500 |

每張訂單在這份結果裡只有一列，對它加總金額時每張訂單也就只算一次。

不可加的（平均、中位數、百分位）不能先在每張訂單這一層算完，再拿到更粗的那一層合併。先算每張訂單的平均星等、再把這些平均值平均一次，得到的是「平均的平均」：評價則數多的訂單與只有一則的訂單權重一樣，結果就偏了。DISTINCT 在這裡也沒有幫助，它去掉的是重複的值，不是重複的列。再替訂單 102 加一則一星評價，讓兩張訂單的則數不同：

1INSERT INTO 評價 VALUES (9003, 102, 1);
2
3-- 平均的平均：101 的兩則平均 4、102 的一則平均 1，再平均一次
4SELECT avg(每單平均) FROM (SELECT 訂單編號, avg(星等) AS 每單平均 FROM 評價 GROUP BY 訂單編號);
5-- 2.5

佳穎收到的三則評價是 5、3、1，實際的平均是 3。平均與中位數、百分位的出路不同。

平均可以拆成兩個可加的量。 子查詢裡同時算 sum 與 count，接上來之後各自加總，最後才相除：

1SELECT 顧客.姓名, sum(評價統計.星等總和) * 1.0 / sum(評價統計.則數) AS 平均星等
2FROM 顧客
3JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4JOIN (SELECT 訂單編號, sum(星等) AS 星等總和, count(*) AS 則數 FROM 評價 GROUP BY 訂單編號) AS 評價統計
5  ON 評價統計.訂單編號 = 訂單.訂單編號
6GROUP BY 顧客.姓名;
7-- 佳穎 | 3.0

sum 與 count 在每一層都可以直接相加，所以不管中間經過幾層彙總，最後相除的都是全部評價的總和與總則數。乘上 1.0 是為了避免兩個整數相除時被截成整數。

中位數與百分位拆不成可加的量。 知道兩張訂單各自的中位數，推不出兩張合起來的中位數，所以它們只能在目標層次上，直接對原始的列計算，而且每一筆資料在那個集合裡只能出現一次。算「每位顧客收到的評價星等中位數」時，要計算的集合是評價的列，而顧客接訂單再接評價，每一則評價正好出現一次，這個集合可以直接用；如果連接裡還接了會讓評價重複的表，就要先把評價收成「每則一列」再算。計算本身各家的寫法不同。SQLite 的 median() 與 percentile() 屬於可選的擴充，手上那一份有沒有，跑一次 SELECT median(1); 就知道；沒有的話用視窗函數替每位顧客的評價排序，取中間那一列，則數是偶數時取中間兩列的平均：

 1-- 此時佳穎收到的評價是 5、3、1
 2-- PostgreSQL：percentile_cont 在每一組裡依 ORDER BY 排好之後取 0.5 分位
 3SELECT 顧客.姓名, percentile_cont(0.5) WITHIN GROUP (ORDER BY 評價.星等) AS 中位數
 4FROM 顧客
 5JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 6JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
 7GROUP BY 顧客.姓名;
 8-- 佳穎 | 3
 9
10-- SQLite 沒有 median() 時：名次是那位顧客的評價依星等排序後的位置，則數是那位顧客的評價總數
11WITH 排序後 AS (
12  SELECT 顧客.姓名, 評價.星等,
13         row_number() OVER (PARTITION BY 顧客.顧客編號 ORDER BY 評價.星等) AS 名次,
14         count(*)     OVER (PARTITION BY 顧客.顧客編號) AS 則數
15  FROM 顧客
16  JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
17  JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
18)
19SELECT 姓名, avg(星等) AS 中位數 FROM 排序後
20WHERE 名次 IN ((則數 + 1) / 2, (則數 + 2) / 2)   -- 則數是奇數時兩個值相同，偶數時是中間兩列
21GROUP BY 姓名;
22-- 佳穎 | 3.0

這一段的例子做完之後把 9003 刪掉：DELETE FROM 評價 WHERE 評價編號 = 9003;。下一節要用到訂單 102 沒有評價的狀態。

外連接補出來的 NULL：count(*) 與 count(欄位) 的差別

外連接配不上時補的 NULL，來源表裡並不存在。LEFT / RIGHT / FULL 各自保護哪一側、因此在哪一側補空缺，定義在 Outer Join（外連接）。count 對它的處理與一般的值不同：

1SELECT count(*) AS 全部列, count(評價.星等) AS 有星等的列
2FROM 訂單 LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
3-- 3 | 2

count(*) 數的是列，count(欄位) 數的是那一欄有值的列。差額就是空缺的數量。這個差別在沒有連接的查詢裡很少現形，因為原始資料多半沒那麼多空值。

NULL 的比較結果與 IS NULL

要找出沒下過單的顧客，很自然會寫成「訂單編號等於 NULL」：

 1SELECT 顧客.姓名 FROM 顧客
 2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 3WHERE 訂單.訂單編號 = NULL;
 4-- 0 列，而且沒有任何錯誤訊息
 5
 6-- 同一段改成 IS NULL
 7SELECT 顧客.姓名 FROM 顧客
 8LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 9WHERE 訂單.訂單編號 IS NULL;
10-- 宗翰、雅文

= NULL 那一段在三個引擎上都回零列、都不報錯。這個 IS NULL 要寫在 WHERE 而不是 ON，理由是它描述的是連接完成之後的那份結果；同一個條件放兩邊為什麼在外連接底下留下不同的列，在 SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責。

原因是 NULL 表示「這裡沒有值」，而拿一個未知的值去比對任何值，答案也是未知：

1SELECT (NULL = NULL), (NULL IS NULL);
2-- NULL | 1        SQLite 用 1 表示真

NULL = NULL 的結果既不是真也不是假，它是第三種答案。而 WHERE 只留下判斷為真的列，所以「未知」與「假」在這一步的下場相同——列被丟掉。

IS NULL 是另一個運算子，它問的是「這個位置有沒有值」，答案只有真或假兩種。判斷空缺一律用 IS NULL 與 IS NOT NULL，比較運算子在這件事上永遠回零列。

子查詢含 NULL 時的 NOT IN 與 NOT EXISTS

同一套三值邏輯（見 NULL）製造了一個更難發現的形態。書店要找出沒下過單的顧客，改用 NOT IN：

1SELECT 姓名 FROM 顧客 WHERE 顧客編號 NOT IN (SELECT 顧客編號 FROM 訂單);
2-- 共用資料：宗翰、雅文

答案正確。接著訂單表多了一列顧客編號是 NULL 的資料——比如一筆還沒綁定顧客的訂單。同一段查詢再跑一次，三個引擎都是零列，仍然不報錯：

1INSERT INTO 訂單 VALUES (103, NULL, '2026-03-10', 200);
2
3SELECT 姓名 FROM 顧客 WHERE 顧客編號 NOT IN (SELECT 顧客編號 FROM 訂單);
4-- 0 列
5--   子查詢交出 1、1、NULL，NOT IN 對宗翰（顧客編號 2）展開成 2 <> 1 AND 2 <> 1 AND 2 <> NULL
6--   與 1 比較的兩項為真，與 NULL 比較的那一項是未知，AND 的結果是未知，WHERE 不留

NOT IN 展開成一串「不等於」的 AND，與 NULL 比較的那一項答案是未知，整串的結果因此永遠不會是真。子查詢裡出現任何一個 NULL，NOT IN 就對每一列都回答「未知」。

改成 NOT EXISTS 不受影響：

1SELECT 姓名 FROM 顧客
2WHERE NOT EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);
3-- 共用資料：宗翰、雅文
4-- 訂單 103 進來之後：宗翰、雅文
5
6-- 刪掉 103：留著的話，金額最高的那段查詢會把它也選進來
7DELETE FROM 訂單 WHERE 訂單編號 = 103;

NOT EXISTS 問的是「有沒有配得上的列」，那是一個關於存在性的問題，答案只有真假兩種。

這個安全範圍限定在子查詢用等號配對的時候。 子查詢裡改用不等號比較的話，NULL 一樣會讓結果出錯。「找出每位顧客金額最高的訂單」可以寫成「同一位顧客沒有另一張金額更高的訂單」，而金額為 NULL 的那張訂單會被選成「最高」。原因不是 NULL 比較大：NULL 沒有進到 NOT EXISTS 的答案裡，它進到了子查詢的比較條件裡，比較的答案是未知而不是真，子查詢因此一列都找不到，NOT EXISTS 於是成立。在共用資料上加一張金額未填的訂單 104 就看得到：

 1INSERT INTO 訂單 VALUES (104, 1, '2026-03-12', NULL);
 2
 3SELECT a.訂單編號, a.金額 FROM 訂單 a
 4WHERE NOT EXISTS (SELECT 1 FROM 訂單 b WHERE b.顧客編號 = a.顧客編號 AND b.金額 > a.金額);
 5-- 102 | 500    子查詢對 102 找不到金額更高的訂單
 6-- 104 |        子查詢比的是 b.金額 > NULL，對每一張 b 都是未知，一列都找不到
 7--   101 沒有出現：102 的 500 > 300 為真，子查詢找得到一列
 8
 9-- 子查詢之外另寫 a.金額 IS NOT NULL，排除金額未填的那一張
10SELECT a.訂單編號, a.金額 FROM 訂單 a
11WHERE a.金額 IS NOT NULL
12  AND NOT EXISTS (SELECT 1 FROM 訂單 b WHERE b.顧客編號 = a.顧客編號 AND b.金額 > a.金額);
13-- 102 | 500
14
15DELETE FROM 訂單 WHERE 訂單編號 = 104;

佳穎的「金額最高的訂單」在沒有 IS NOT NULL 的那段查詢裡回了兩張：真正最高的 102，以及金額未填的 104。

列數改變、空缺與 NULL 比較的共同來源

列數變了、空缺出現了、空缺的比較是第三種答案——三者都來自同一件事：FROM 產出的是一個新的關係，而後續每一步都在它上面操作。 拿來源表的直覺去讀後面的子句，就會在這三個地方各撞一次。

列數會變與空缺會出現，在本篇是給定的，而兩者各自在更早的時候就決定了。列數會不會膨脹，由常一起取的資料切在幾張表決定；空缺存不存在，由這一欄允不允許為空決定——兩個都是建表時下的，下的當下看不出代價。backend 1.16 Schema 設計決定的查詢代價 各給一節，並量出雙重展開讓聚合翻倍，以及 DISTINCT 這個修法對不對由資料決定。

列數膨脹與比較 NULL 的錯誤各有各的機制，而共通的是引擎對它們都沒有回報的管道：列數膨脹的結果列數與欄位看不出異常，而計數與總額已經多算；等號比 NULL 與 NOT IN 回零列，而零列與「確實沒有」分不開；NOT EXISTS 子查詢裡的不等號多留了金額未填的那張訂單，多出來的那一列也是一張真實存在的訂單。SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 拿列數膨脹當例子，說明結果的形狀正確為什麼不構成保證。

一張表只出現一次的時候，這個區別沒有作用。出現兩次就有：兩次出現共用同一個名字，引擎分不出某個欄位屬於哪一次，於是擋下來。

引擎把這件事講得很明白，而擋下來的時機分兩種。PostgreSQL 與 DuckDB 看到重複的名字就停，訊息分別是 table name "訂單" specified more than once 與 Duplicate alias "訂單" in query!；SQLite 讓查詢往下走，等到某個欄位引用無從分辨時才回 ambiguous column name。表名本身就是預設的別名，所以同一張表的兩次出現共用同一個名字時，等於兩次出現叫同一個稱呼，之後每一次引用都無從分辨。

兩張表共用欄名時的欄位歸屬

欄位的歸屬要靠名字決定，所以兩張不同的表共用一個欄名時同樣分不開。書店的顧客表與訂單表都有 顧客編號：

1SELECT 顧客編號 FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- MySQL:  ERROR 1052: Column '顧客編號' in field list is ambiguous
3-- SQLite: ambiguous column name: 顧客編號
4-- DuckDB: Ambiguous reference to column name "顧客編號"

id 是這件事最常撞到的欄位名，因為多數表都有一個。連接之後每個欄位引用都要能追回它屬於哪一次出現，加上表名或別名當前綴就解決。

自連接只是這個規則的極端情形：兩次出現連表名都一樣，所以連前綴都救不了，非取別名不可。

表一多，要判讀的就變成每個 ON 引用得到哪些出現——寫在它上面的那些出現都已經併進左運算元，寫在它下面的還沒進來。SQL.4 鏈式連接的左運算元 寫左運算元隨著往下走而變大的過程。

用別名分開同一張表的兩次出現

訂單表裡的兩張單都掛在佳穎名下。要找出同一位顧客的訂單先後配對——哪一張在前、哪一張在後。這件事需要把訂單表的兩列擺在一起比較，而一列一列處理的查詢做不到，除非讓訂單表出現兩次：

1SELECT 早.訂單編號, 早.下單日, 晚.訂單編號, 晚.下單日
2FROM 訂單 AS 早
3JOIN 訂單 AS 晚 ON 早.顧客編號 = 晚.顧客編號 AND 早.下單日 < 晚.下單日;
4-- 101 | 2026-03-02 | 102 | 2026-03-09

早 與 晚 是同一張表的兩次出現。連接條件在做兩件事：顧客編號 相同把配對限制在同一個人身上，下單日 的大小關係決定哪一次出現扮演「早」、哪一次扮演「晚」。

條件裡的第二項是這個寫法的重點。 少了它，每張訂單會跟同一位顧客的每張訂單配對一次，包括跟自己配。加上嚴格的大小比較之後，每一對只留下一個方向，而同一張訂單跟它自己組成的那一對，因為兩邊日期相等也被排除。同一位顧客有三張訂單時，每兩張各配一次，不多不少：

 1-- 拿掉日期的比較，只留顧客編號相同
 2SELECT 早.訂單編號, 晚.訂單編號
 3FROM 訂單 AS 早
 4JOIN 訂單 AS 晚 ON 早.顧客編號 = 晚.顧客編號;
 5-- 共用資料：101|101、101|102、102|101、102|102（兩個方向各一次，加上各自跟自己配）
 6
 7-- 日期的比較放回去
 8SELECT 早.訂單編號, 晚.訂單編號
 9FROM 訂單 AS 早
10JOIN 訂單 AS 晚 ON 早.顧客編號 = 晚.顧客編號 AND 早.下單日 < 晚.下單日;
11-- 共用資料：101|102
12-- 佳穎多一張 103（下單日 2026-03-15）之後：101|102、101|103、102|103

自連接的適用問題：前後配對、同組比較與層級關係

自連接處理的是同一批資料裡兩筆資料之間的關係——兩列，不是兩個欄位。一列一列的處理看不到這種關係，因為每一列在被判斷的時候不知道其他列長什麼樣子。

自連接常見的形態有三種。前後配對：同一位顧客的訂單先後配對，把時間上相鄰或有先後關係的兩列擺在一起。同組比較：找出訂單金額高於同一位顧客其他訂單的那些，比較的對象是同一張表裡的兄弟列。層級關係：一張員工表裡每個人有一個主管欄位指向同一張表的另一列，要把人與他的主管一起列出來時，員工表出現兩次，一次當員工、一次當主管。

前後配對、同組比較與層級關係三種的共同點是要比較的兩列住在同一張表裡。需不需要自連接由兩個獨立的問題決定：這個問題要不要拿一列去跟同一張表的另一列比——不比的問題不屬於這一族；以及要不要把另一列的欄位輸出出來——這個問題決定族裡選哪一種寫法。

要不要輸出另一列的欄位，就是 SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理 那條判斷標準——自連接也是一種 JOIN，所以它同樣適用。只是判斷「有沒有另一列符合條件」而不輸出它，用 EXISTS 比自連接省一次配對展開；要把兩列並排列出來（像上面的訂單先後配對），才非自連接不可。

省下的量由配對會不會膨脹決定，所以這條判斷標準要連著連接鍵唯不唯一一起看。 連接鍵在對面那一次出現裡唯一的時候，一列只配得到一列，兩種寫法產出的列數相同，EXISTS 省下的是零——那時選哪一個回到讀起來哪一個貼合意圖。一列配得到多列的時候展開才會發生，而那正是 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯 寫的列數膨脹。判斷的動作是問這個連接鍵在對面那一次出現裡唯不唯一，而唯一與否要由約束回答，不由現在這批資料回答。

同組比較最常見的題型是每組最大值，而它套用「要不要輸出另一列的欄位」這條判斷標準時，答案是不輸出。 「找出每位顧客金額最高的訂單」輸出的是那張訂單自己的欄位，同顧客的其他訂單只拿來比大小，所以寫成 NOT EXISTS 就夠。前後配對的「找出每筆訂單與同顧客下一筆的差額」則要用到另一列的金額，那就非自連接不可。

每組最大值的條件是比大小，而比大小自己會帶出兩個邊界：並列的最大值與可為空的比較欄。NOT EXISTS 會把並列的那幾筆全部留下，要只留一筆得另外加一個決勝的條件，通常取編號最小的那筆。NULL 跟誰比都判不成真，所以「同顧客裡沒有比它大的」對金額是 NULL 的那一張恆成立，它會被選成最大；要排除它，IS NOT NULL 得寫在外層查詢——子查詢裡的比較對它本來就判不成真，寫在那裡攔不住（機制見 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

 1-- 每位顧客金額最高的訂單：同顧客裡找不到比它大的那一張
 2SELECT o.訂單編號, o.金額
 3FROM 訂單 o
 4WHERE NOT EXISTS (
 5  SELECT 1 FROM 訂單 i
 6  WHERE i.顧客編號 = o.顧客編號 AND i.金額 > o.金額
 7);
 8-- 共用資料：102 | 500
 9-- 佳穎多一張 103（金額 500）之後：102 | 500、103 | 500（並列的兩張都留下）
10-- 佳穎多一張 104（金額 NULL）之後：102 | 500、104 | NULL（NULL 那一張被選成最大）
11
12-- 決勝的條件：金額相同時，編號較小的那一張也算「比它大」
13SELECT o.訂單編號, o.金額
14FROM 訂單 o
15WHERE NOT EXISTS (
16  SELECT 1 FROM 訂單 i
17  WHERE i.顧客編號 = o.顧客編號
18    AND (i.金額 > o.金額 OR (i.金額 = o.金額 AND i.訂單編號 < o.訂單編號))
19);
20-- 佳穎多一張 103（金額 500）之後：102 | 500
21
22-- 排除金額是 NULL 的那一張：條件寫在外層
23SELECT o.訂單編號, o.金額
24FROM 訂單 o
25WHERE o.金額 IS NOT NULL
26  AND NOT EXISTS (
27    SELECT 1 FROM 訂單 i
28    WHERE i.顧客編號 = o.顧客編號 AND i.金額 > o.金額
29  );
30-- 佳穎多一張 104（金額 NULL）之後：102 | 500
31-- 同一句改寫進子查詢（AND i.金額 IS NOT NULL）：仍回 102 | 500、104 | NULL

表只出現一次時別名的作用

同一張表只出現一次的時候，別名的作用是縮短欄位引用。長表名在有三四張表的查詢裡會讓每個欄位引用都變得很長，取一個短別名之後可讀性差很多。

而作用不只是省字。取了別名之後原本的表名在這個查詢裡就不再是它的稱呼，三個引擎都會擋下來：PostgreSQL 回 invalid reference to FROM-clause entry for table "訂單" 並附上一句提示要改用別名，SQLite 回 no such column，DuckDB 回 Referenced table "訂單" not found。FROM 訂單 AS 早 宣告的是「這次出現叫早」，而宣告過後就只有這一個稱呼。

別名的取名：標示這次出現扮演的角色

自連接的兩次出現在問題裡扮演不同角色，而別名是查詢裡唯一標示角色的地方。同一位顧客的訂單先後配對：

1SELECT 早.訂單編號, 晚.訂單編號, 晚.金額 - 早.金額
2FROM 訂單 早 JOIN 訂單 晚
3  ON 晚.顧客編號 = 早.顧客編號 AND 晚.下單日 > 早.下單日;

把兩個別名換成 a 與 b，查詢的行為一模一樣，而 b.金額 - a.金額 這一行要回頭看 ON 才知道哪一個是後來那張單。判斷標準落在這裡：讀到用它的那一行時，方向自己說得出來。 名字取得對的時候，晚.金額 - 早.金額 讀起來就是它的意思。

引擎對這個名字沒有意見。把兩個別名對調，條件也跟著對調：

1FROM 訂單 晚 JOIN 訂單 早
2  ON 早.顧客編號 = 晚.顧客編號 AND 早.下單日 > 晚.下單日

叫「早」的那一次出現拿到的是後來那張單。查詢照跑，結果與上面那一段相同，而每一個名字都指反了。別名因此也是一種宣告——它說明這次出現代表什麼，兌現與否由寫的人負責。

表的別名與欄位別名各自可用的時機

SELECT 裡的 AS 替算出來的欄位取名，FROM 裡的 AS 替表的一次出現取名。兩者的作用範圍不同，可用的時機也不同。

表的別名在 FROM 那一步就成立，所以 WHERE、GROUP BY、ON 全部用得到它。欄位別名到 SELECT 那一步才誕生，所以 WHERE 照語意模型用不到。兩個 AS 長得一樣而落在求值順序的兩端。

某些引擎讓 WHERE 用得到欄位別名，那是引擎的放寬，不是模型的規定。SQL.2 子句的求值順序 走過每一步能用到哪些欄位與值，並把模型層擋得住的限制與各家引擎自己放寬的分開——表的別名不在它的範圍裡，因為別名在 FROM 那一步就成立了。

分開它們的問題只有一個：除了判斷有沒有，還要不要用到被比對的那張表的欄位。

同一題用 IN、EXISTS 與 JOIN 各寫一次

書店的三位顧客裡只有佳穎下過單，兩張都是她的。要找出下過單的顧客。

IN 問的是成員資格——這個顧客編號在不在括號裡那個子查詢交出的清單裡：

1SELECT 姓名 FROM 顧客 WHERE 顧客編號 IN (SELECT 顧客編號 FROM 訂單);
2-- 佳穎

EXISTS 問的是存在性——有沒有至少一張訂單屬於這位顧客：

1SELECT 姓名 FROM 顧客
2WHERE EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);
3-- 佳穎

JOIN 做的是另一件事——把兩張表併成一個新的關係：

1SELECT 顧客.姓名 FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- 佳穎、佳穎

同一個「找出下過單的顧客」的問題，IN 與 EXISTS 回一列而 JOIN 回兩列——佳穎在 JOIN 的結果裡出現了兩次。

列數：條件與連接的差別

IN 與 EXISTS 出現在 WHERE 裡，它們是條件。條件對每一列只做一件事——留下或丟掉——所以顧客表有三列，過完條件最多剩三列，一列都不會多出來。

JOIN 出現在 FROM 裡，它參與的是關係的組成。佳穎配得上兩張訂單，於是她在新的關係裡出現兩次（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。加上 DISTINCT 之後結果才與 IN、EXISTS 一致：

1SELECT DISTINCT 顧客.姓名 FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- 佳穎

需要 DISTINCT 這件事本身是一個訊號：它表示這個查詢只是要判斷有沒有，而 JOIN 順便做了不需要的配對。這種時候 IN 或 EXISTS 更貼合意圖，因為它們一開始就沒有把列複製出來。

IN 與 EXISTS 做的運算在關聯代數裡叫半連接：顧客表與訂單表配對之後只留下顧客表的列，每一列至多出現一次。否定式的 NOT EXISTS 留下顧客表裡配不到任何訂單的列，叫反連接（Semi-join 與 Anti-join（半連接與反連接））。

可取用的欄位：被比對的那張表在不在 FROM 裡

要列出每位顧客的訂單金額，JOIN 是最直接的一條路：

1SELECT 顧客.姓名, 訂單.金額 FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- 佳穎 300 / 佳穎 500

同一件事用 IN 寫不出來：

1SELECT 姓名, 訂單.金額 FROM 顧客 WHERE 顧客編號 IN (SELECT 顧客編號 FROM 訂單);
2-- SQLite: no such column: 訂單.金額
3-- DuckDB: Referenced table "訂單" not found!

錯誤訊息說得很直接：訂單 這張表不在 FROM 裡面。子查詢是一個獨立的查詢，它算完之後只交出一份值的清單，而訂單表沒有成為外層 FROM 的一部分——外層因此引用不到它的任何欄位。

帶欄位出來還有另一條路——把子查詢寫在 SELECT 裡並讓它引用外層的欄位。引用外層欄位的子查詢叫相關子查詢（correlated subquery）：

1SELECT 姓名, (SELECT 金額 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號
2              ORDER BY 訂單編號 LIMIT 1) FROM 顧客;
3-- 佳穎 300 / 宗翰 NULL / 雅文 NULL

它一次只交得出一個值，所以要多欄或多列時仍然回到 JOIN；而它的執行方式是逐列的，代價怎麼算見 SQL.17 查詢的代價：資料分布、索引與寫法各自的影響。

這時候佳穎出現兩次是對的，因為問的是每一張訂單的金額，而她確實有兩張。這一題本來就要每張訂單各佔一列，所以列數變多正是這個寫法要交出來的東西。

選用的判斷標準：要不要用到被比對那張表的欄位

要不要用到被比對的那張表的欄位。 要用到就得 JOIN，因為只有它把那張表帶進 FROM。這時候要順帶檢查列數是不是預期內的——後面如果接聚合，sum 與 count 算的是配對後的列；這個膨脹怎麼發生、可加與不可加的聚合各自怎麼修，在 SQL.6 連接之後的列數與空缺。

只是判斷有沒有，就用 IN 或 EXISTS。它們是條件，對每一列只做留或丟，寫出來的意圖比 JOIN 加 DISTINCT 清楚——而哪一種比較快是另一個問題，答案取決於資料與索引。SQL.17 查詢的代價 用一道重複值的題目量分組、自連接與 EXISTS 三種寫法，並示範加一個索引之後排名重排——EXISTS 從最慢掉到與分組同一個量級。

IN 與 EXISTS 的分岔：子查詢含 NULL 時的否定式

IN 與 EXISTS 在「有沒有」這件事上同值，而在一個地方分岔：子查詢的結果裡有 NULL 的時候。

清單裡只要混了一個 NULL，NOT IN 就再也不會為真：值在清單裡的列判成明確的假，值不在清單裡的列因為那個 NULL 判成未知，兩種都被 WHERE 丟掉，整段查詢回零列且不報錯；NOT EXISTS 不受影響。在共用資料上多一張沒填顧客編號的訂單就看得到：

1INSERT INTO 訂單 VALUES (103, NULL, '2026-03-20', 100);   -- 訂單 103 沒有填顧客編號
2
3SELECT 姓名 FROM 顧客 WHERE 顧客編號 NOT IN (SELECT 顧客編號 FROM 訂單);
4-- 共用資料：宗翰、雅文
5-- 多了訂單 103 之後：零列，不報錯（子查詢交出的清單是 1、1、NULL）
6
7SELECT 姓名 FROM 顧客
8WHERE NOT EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);
9-- 共用資料與多了訂單 103 之後都是：宗翰、雅文

完整的推導在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯，包括 NOT EXISTS 的安全範圍為什麼限定在等號配對。零列與「確實沒有」在結果上分不開，所以 NOT IN 碰到 NULL 的錯只能靠寫的人預先知道「子查詢有 NULL 時 NOT IN 會失效」那條規則——SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 把它歸成誤解語意模型：寫的人對某條規則的預期與語意模型的規定不同，而誤解語意模型修得掉，改對之後永遠對。

所以肯定式的 IN 與 EXISTS 可以按可讀性挑，而否定式一律用 NOT EXISTS——除非能保證子查詢那一欄不會有 NULL，而那個保證要來自約束而不是來自習慣：翻遍現在的資料都沒有 NULL 只證明此刻沒有，而查詢要活得比這一批資料久。

還有一個形態上的差別：本篇 IN 的子查詢與外層無關，可以單獨拿出來執行，叫獨立子查詢；EXISTS 的子查詢引用了外層的欄位，離開外層就跑不動，是相關子查詢。讀陌生的查詢時，看子查詢裡有沒有出現外層的表名，就分得出它是算一次的獨立子查詢，還是對外層每一列各問一次的相關子查詢。

「語意相同就按可讀性挑」這個處置的適用範圍不只 IN、EXISTS 與 JOIN 這三種寫法：哪幾類寫法差異是免費的、哪一類會與效能分岔，在 SQL.21 可讀性與執行代價：兩者一致與分岔的情形。

選錯鍵的時候查詢照樣跑得動，只是每一組代表的對象與寫查詢的人預期的不同。

外連接之後用右表的欄位當分組鍵

書店的三位顧客裡只有佳穎下過單，兩張都是她的。要找出一張單都沒下的顧客，用 LEFT JOIN 接起來之後按訂單那一側的顧客編號分組：

1SELECT 訂單.顧客編號 AS 分組鍵, count(*) AS 這組幾列,
2       count(訂單.顧客編號) AS 有值幾列, group_concat(顧客.姓名) AS 裝了誰   -- group_concat 把一組裡的名字串起來
3FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
4GROUP BY 訂單.顧客編號;

MySQL、SQLite 與 DuckDB 的答案一致：

1分組鍵  這組幾列  有值幾列  裝了誰
2NULL    2         0         宗翰,雅文
31       2         2         佳穎,佳穎

宗翰與雅文被併進同一組。 他們沒有配到訂單，外連接給他們的 訂單.顧客編號 都是 NULL，而 GROUP BY 把值相同的列收成一組——GROUP BY 對 NULL 的處理與比較運算不同：鍵同樣是 NULL 的那些列會被收進同一組，所有沒配到的列因此共用同一個鍵。分組是少數 NULL 表現得像一般值的地方，它在比較與 NOT IN 上的表現剛好相反，那兩處的表現寫在 SQL.6 連接之後的列數與空缺；這些 NULL 是連接補上的、不是資料裡本來的空值，兩種來源的分別在 Outer Join（外連接）。

接著用 HAVING count(訂單.顧客編號) = 0 挑出沒下過單的那一組，這個條件本身是對的：它確實選中了那一組，因為 count(欄位) 只數有值的列而那一組一列都沒有。選中的是一組，而這一組底下是宗翰與雅文兩列。

輸出非分組欄時各家引擎的反應

輸出顧客姓名時，姓名不在分組鍵裡，於是三家引擎在這裡分岔：

1SELECT 顧客.姓名 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3GROUP BY 訂單.顧客編號 HAVING count(訂單.顧客編號) = 0;

MySQL 8 預設拒絕：

1ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause and contains
2nonaggregated column ... incompatible with sql_mode=only_full_group_by

DuckDB 同樣拒絕。SQLite 接受，從分組鍵是 NULL 的那一組裡任意挑一列回傳——只回宗翰，雅文消失了，而且沒有任何錯誤訊息。

而拒絕的 MySQL 與 DuckDB 擋下的是輸出非分組欄這個寫法，不是選錯的鍵：把姓名補進 GROUP BY 之後三家都照跑，在共用資料上答案也是對的，因為三位顧客不同名。

1SELECT 顧客.姓名 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3GROUP BY 訂單.顧客編號, 顧客.姓名      -- 鍵仍是訂單表的顧客編號，只補上姓名
4HAVING count(訂單.顧客編號) = 0;
5-- 共用資料：宗翰、雅文
6
7INSERT INTO 顧客 VALUES (4, '宗翰');   -- 第二位宗翰，同樣沒下過單
8-- 重跑同一段查詢：宗翰、雅文
9-- 沒下過單的顧客有三位而結果只有兩列：兩位宗翰的鍵都是 (NULL, 宗翰)，被併成一組

鍵錯在它讓不同的顧客共用一個值，而這件事要等資料裡出現同名的人才看得到。選錯鍵的查詢在語法上完全合法，SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 把它歸進問錯了問題的那一類。

選分組鍵的判斷標準：一組代表的對象

一組要代表一位顧客，鍵就是顧客的識別欄位：

1SELECT 顧客.姓名 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3GROUP BY 顧客.顧客編號, 顧客.姓名
4HAVING count(訂單.顧客編號) = 0;
5-- 宗翰、雅文

現在三家引擎都給出兩列。分組鍵換掉之後，沒有任何一組的鍵是 NULL 了——宗翰與雅文各自有不同的顧客編號，所以各自成組，而每一組的訂單計數都是零。

判斷方法：先說出「我要每一組代表什麼」，鍵就是那個對象的識別欄位。 說不出來的時候，多半是這一題根本不需要分組。

鍵還要涵蓋一件事：SELECT 裡沒有被聚合的欄位全部要進 GROUP BY。上面補的 姓名 就是為此——少了它 MySQL 與 DuckDB 會拒絕（正是上一節那個錯誤）。

而補進去的欄位必須由鍵決定——鍵的每一個值只對到這個欄位的一個值，否則分組的粒度會跟著變。 這種關係在資料庫理論裡叫函數相依（functional dependency），MySQL 的 ERROR 1055 完整訊息寫的 not functionally dependent on columns in GROUP BY clause 指的就是它。一個顧客編號只對到一個姓名，所以補姓名不影響分組；要求的方向是從鍵到欄位，反方向不必成立——兩位宗翰就是同一個姓名對到兩個顧客編號，而按顧客編號分組時他們仍然各自成組。下單日不由顧客編號決定：把它補進 GROUP BY，同一位顧客的每一個下單日各自成組，計數從「這位顧客有幾張單」變成「這位顧客在這一天下了幾張單」，而引擎不會報錯：

1SELECT 顧客.姓名, 訂單.下單日, count(訂單.顧客編號) AS 張數 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3GROUP BY 顧客.顧客編號, 顧客.姓名, 訂單.下單日;
4-- 佳穎 | 2026-03-02 | 1
5-- 佳穎 | 2026-03-09 | 1      佳穎被拆成兩組
6-- 宗翰 |            | 0
7-- 雅文 |            | 0
8-- 拿掉下單日、只按顧客編號與姓名分組時：佳穎 | 2、宗翰 | 0、雅文 | 0

所以不由鍵決定的欄位不能靠補進鍵來輸出，要用聚合包起來（max(下單日) 這種），讓它回到「這一組的某個值」而不是「這一組的分法」。

鍵只決定一組由誰構成；算完之後原本的列還留不留，是分組與視窗函數分開的地方，SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列 用同一批訂單並排兩種產出。

不需要分組的問題：存在性判斷

把分組鍵換成顧客編號、再補上姓名的那個修正讓查詢回出正確答案，而更前面還有一個問題沒被問：這一題需要分組嗎。

從業務事實推一次。沒消費過的顧客，在訂單表裡不會有任何一列。 這句話有一個可以直接驗證的推論——「他的訂單數是零」這件事，從訂單表本身問不出來：

1SELECT 顧客編號, count(*) FROM 訂單 GROUP BY 顧客編號;
2-- (1, 2)

只有佳穎。宗翰與雅文不在結果裡，因為訂單表沒有他們的列，所以沒有一組可以代表他們，也就沒有計數可以是零。

那個零是外連接造出來的。 LEFT JOIN 替他們各生一列全是 NULL 的假訂單，count(欄位) 數那一列得到零。所以「計數等於零」是查詢自己製造出來再讀回去的產物，而不是資料本身帶著的性質。

計數預設有列可以數，而這一題的對象恰好是什麼都沒有的那些人。這就是分組那條路從一開始就對不上的來源，比鍵選錯更上一層。

翻成 SQL 最貼字面的形式是存在性判斷：

1SELECT 姓名 FROM 顧客
2WHERE NOT EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);
3-- 宗翰、雅文

一句話對一句話——「找不到對應訂單的顧客」。沒有分組、沒有計數。同一件事也寫得成外連接，兩者都對：

1SELECT 顧客.姓名 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3WHERE 訂單.訂單編號 IS NULL;   -- 訂單編號只有在外連接補出來的列上是 NULL
4-- 宗翰、雅文

差別在描述的路徑——NOT EXISTS 直接說「找不到」，外連接那一版先讓每位顧客都保留下來、再挑出補了 NULL 的那些。SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 從條件該放哪一邊的角度走同一題，兩篇的結論一致。

GROUP BY 是換單位的工具，用在單看一列答不出來的問題上——「這位顧客下了幾張單」「哪張訂單被評價超過兩次」那一類。判斷沿用 SQL.2 子句的求值順序：這個條件需不需要看到組裡的其他列才能回答。不需要就留在 WHERE，連 GROUP BY 都不必寫。求值順序那一篇走過從 FROM 到 LIMIT 每一步處理的單位，分組前後從列換成組是其中變化最大的一步。

三種寫法各自描述什麼、以及 NOT IN 為什麼在這裡是危險的那一個，在 SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理。

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。

SQL 用 EXISTS 與 NOT EXISTS 表達這兩個運算，語言本身沒有為它們保留關鍵字：

1-- 半連接：下過單的顧客
2SELECT 姓名 FROM 顧客
3WHERE EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);
4
5-- 反連接：從未下單的顧客
6SELECT 姓名 FROM 顧客
7WHERE NOT EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號);

名字裡的「半」指結果只帶走一邊

三個運算作用在同一對關係上，差別在結果帶走什麼。

右邊那份資料在這兩個運算裡的角色是條件，它的欄位到不了結果。要把右邊的欄位列出來就得用連接，那條判斷標準在 SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理。

列數上限省掉去重這一步

半連接問的是配不配得到，所以配到幾筆不影響結果——一位顧客手上有兩張訂單或二十張訂單，EXISTS 都只讓她出現一次。同一個問題用連接寫，她會照訂單張數各出現一次，要補 DISTINCT 把複製出來的列收掉（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

需要 DISTINCT 因此是一個訊號：這個查詢問的是有沒有，而連接順便做了它不需要的配對。

反連接有兩條描述路徑

NOT EXISTS 直接說「找不到」。外連接那一版先讓左邊每一列都保留下來，再挑出補了 NULL 的那些：

1SELECT 顧客.姓名 FROM 顧客
2LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3WHERE 訂單.訂單編號 IS NULL;

兩段回同一批列，路徑不同——一條由條件直接表達，另一條靠外連接補出來的 NULL 當標記。

NOT IN 的行為與這兩條分岔：子查詢的結果裡出現一個 NULL，整段就回零列且不報錯。反連接的安全寫法因此落在 NOT EXISTS 與外連接這兩條上（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

概念位置

半連接與反連接跟連接一樣是導出運算：半連接等於連接之後只投影左邊的欄位再去重，反連接等於左邊減去半連接的結果。關聯代數的正典運算清單因此多半只列到連接，而「有沒有對應資料」這一族問題全部落在這兩個運算上——找出下過單的顧客、找出從未下單的顧客、找出比前一天熱的日子，題目與寫法各異而運算只有這兩個。

計畫上看不看得到這兩個運算的名字，各家不同。DuckDB 1.5.5 把它印成 Join Type: SEMI；SQLite 3.51.0 沒有對應的運算子，它把 EXISTS 的子查詢編成帶一個 LIMIT 1 計數器的迴圈，找到第一筆就跳出去——語意相同，而執行計畫上只看得到一個子查詢節點。

它們與積分別是連接結果大小的兩個極端。積是條件缺席時的上限，列數是兩邊相乘；半連接把上限壓到左邊的列數，因為右邊配到幾列都只算一次。中間那一段是連接，結果的大小由配對的重複程度決定。

往下走

IN、EXISTS 與 JOIN 在列數與可取用欄位上的差別、以及選哪一種只問一句話，在 SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理。從一句業務描述推到反連接、以及為什麼計數那條路走不通，在 SQL.9 分組鍵的選擇：鍵與一組所代表的對象。同一張表的兩列互相比較時這兩個運算長什麼樣，在 SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接。同一組寫法的快慢隨索引與資料分布重排的實測，在 SQL.17 查詢的代價。

宣告與行為分岔的時候，查詢照常回正確答案，測試照常通過，執行計畫上也看不出異常。付出代價的是下一個改它的人：他讀到的是宣告，於是他手上的前提從一開始就是錯的。宣告與行為之外，還有一種落差在查詢與要問的問題之間：查詢在語法上完全合法、引擎照實執行，而它回答的不是要問的那一題，那一種在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法；同一段文字換一家引擎會做什麼，是跨引擎的那一種，在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。本篇的宣告落空時答案仍然正確，錯的是文字對下一個讀它的人說的話。

本篇的查詢跑在共用的範例資料庫上：三位顧客佳穎、宗翰、雅文，而只有佳穎下過兩張訂單（101 與 102，金額 300 與 500）。讀這一篇需要先有三件事：LEFT 保護了哪些列在 SQL.4 鏈式連接的左運算元，它與條件位置的互動在 SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責，連接怎麼把一列變成多列在 SQL.6 連接之後的列數與空缺。那三篇答的是「這個關鍵字做什麼」，這一篇不重寫那些機制，它問的是同一段查詢對下一個讀它的人說了什麼。

各個關鍵字的宣告與落空的形態

LEFT JOIN 說的是「右邊配不到對象的左邊那些列也要留著」。寫的人選它，等於宣告他預期有配不到的列，而且那些列對答案有意義。

CROSS JOIN 說的是「我要每一種配對」。DISTINCT 說的是「這一組值本身會重複，而重複對我沒有意義」。COALESCE 說的是「這裡會有空值」。表的別名也是一種宣告：FROM 訂單 AS 早 說的是「這一次出現代表較早的那張單」。這些宣告是免費的，寫下去沒有人會查證。

落空的樣子不只一種。宣告可能被同一段查詢的別的部分撤銷（LEFT 加上一個問右表的 WHERE）、可能描述一個引擎並沒有執行的動作（CROSS 加等值條件）、可能描述一個從一開始就不存在的情況（配對已有保證時的 LEFT），也可能指向錯的成因而答案仍然正確（DISTINCT 收掉連接製造的重複），還可能名字與它代表的那一次出現對調（叫「早」的別名拿到後來那張單，條件跟著對調，結果不變，這個例子在 SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接）。這幾種落空在現有資料上都回正確答案，代價都落在下一個照著宣告動手的人身上：DISTINCT 指向錯成因，他多要一個欄位就回出錯的結果；被撤銷的 LEFT 讓他改了 SELECT 之後仍然少了沒有訂單的顧客，而原因在他沒有動的 WHERE；其餘幾種連錯的結果都不會出現，只讓他下錯判斷。

被 WHERE 撤銷的 LEFT JOIN

書店想找出下過大單的顧客。查詢寫成這樣：

 1SELECT 顧客.姓名
 2FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 3WHERE 訂單.金額 > 200;
 4-- 佳穎、佳穎
 5
 6-- 同一段把 LEFT JOIN 換成 JOIN，其餘不動
 7SELECT 顧客.姓名
 8FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
 9WHERE 訂單.金額 > 200;
10-- 佳穎、佳穎

LEFT 在這裡宣告「沒有訂單的顧客也要留著」。而下一行的 WHERE 問了一個右表欄位，宗翰與雅文那兩列右邊全是 NULL，NULL > 200 答不出真，於是被篩掉，外連接與內連接兩段因此回同樣兩列。

機制在 SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責：條件放 ON 參與配對，放 WHERE 篩成品，而外連接補上的那些列過不了成品這一關。這裡要看的是另一件事——這段查詢的行為是內連接，而它的文字說的是外連接。

下一個維護的人讀到 LEFT，會以為沒下單的顧客在結果裡。他想加一個「顯示零元」的欄位：

1SELECT 顧客.姓名, COALESCE(訂單.金額, 0) AS 金額   -- 他加的欄位：沒有訂單的顧客顯示 0
2FROM 顧客 LEFT JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號
3WHERE 訂單.金額 > 200;                              -- 他沒有動的那一行
4-- 佳穎 300
5-- 佳穎 500

跑出來仍然只有佳穎，而他找不出原因——因為問題在他沒有動的那一行。

CROSS JOIN 加等值條件與內連接的計畫

要比較同一批資料的兩列時，常見的寫法是把表跟自己配對再篩：

1SELECT 今天.訂單編號
2FROM 訂單 昨天 CROSS JOIN 訂單 今天
3WHERE 今天.顧客編號 = 昨天.顧客編號 AND 今天.金額 > 昨天.金額;

CROSS JOIN 宣告「我要每一種配對」，讀起來像是先造出所有配對再挑。而等值條件寫進去之後，最佳化器產出的計畫與內連接的計畫一模一樣。改寫成 JOIN ... ON 的版本把同一個條件搬進 ON：

1SELECT 今天.訂單編號
2FROM 訂單 昨天 JOIN 訂單 今天
3  ON 今天.顧客編號 = 昨天.顧客編號 AND 今天.金額 > 昨天.金額;
4-- 102（CROSS JOIN 那一段也回 102）

同一組資料上兩種寫法的計畫逐字相同：

1-- CROSS JOIN 加 WHERE 等值（SQLite 3.51，共用的範例資料庫，沒有另外建索引）
2|--SCAN 昨天
3|--BLOOM FILTER ON 今天 (顧客編號=?)
4`--SEARCH 今天 USING AUTOMATIC COVERING INDEX (顧客編號=?)
5
6-- JOIN ... ON 同一個條件
7|--SCAN 昨天
8|--BLOOM FILTER ON 今天 (顧客編號=?)
9`--SEARCH 今天 USING AUTOMATIC COVERING INDEX (顧客編號=?)

AUTOMATIC 表示這個索引是引擎為了這一次查詢臨時建的——訂單表上沒有 顧客編號 的索引，而它判斷建一個比逐列掃描划算。兩段查詢連這個決定都一樣。

CROSS JOIN 在代數上確實對應笛卡兒積，而那張卡寫明展開由條件決定：條件把兩邊綁起來時全部組合一次都沒有被造出來。

CROSS JOIN 這個宣告的誤導方向與 LEFT 相反。LEFT 那一節是宣告承諾了引擎沒做的事，這一節是宣告讓讀的人誤判了代價——看到 CROSS 就以為它是列數的平方，於是花力氣改寫一段本來就是內連接的查詢。兩段文字比不出快慢，快慢要向引擎要計畫——SQL.17 查詢的代價 在有無索引的兩種狀態下各量一次；而在這裡要先分清楚：CROSS JOIN 加等值條件與 JOIN ... ON 是同一段查詢的兩種寫法，換掉它省下的是讀的人的疑慮，不是執行時間。

配對已有保證時的 LEFT JOIN

每一張訂單都帶著一個有效的顧客編號時，這樣寫也會過：

1SELECT 訂單.訂單編號, 顧客.姓名
2FROM 訂單 LEFT JOIN 顧客 ON 顧客.顧客編號 = 訂單.顧客編號;

LEFT 宣告「訂單可能找不到顧客」。而兩列訂單都配到了，這個宣告一次都沒有生效過：

1SELECT count(*), count(顧客.姓名)   -- count(*) 數列數，count(欄位) 只數那一欄不是 NULL 的列
2FROM 訂單 LEFT JOIN 顧客 ON 顧客.顧客編號 = 訂單.顧客編號;
3-- 2  2：沒有任何一列是 LEFT 補出來的

它的代價要等到有人相信它才出現。下一個人想查有沒有孤兒訂單（指不到任何顧客的訂單），順手接上這段查詢：

1SELECT 訂單.訂單編號
2FROM 訂單 LEFT JOIN 顧客 ON 顧客.顧客編號 = 訂單.顧客編號
3WHERE 顧客.姓名 IS NULL;            -- 配不到顧客的訂單，姓名會是 LEFT 補上的 NULL
4-- 零列

拿到零列，於是回報「資料乾淨」。零列在這裡有兩種來源：確實沒有孤兒訂單，或者這個宣告本來就沒有內容。這段查詢分不出兩者。

真正保證配對的是約束——外鍵存在時每一張訂單都指得到顧客，那時 LEFT 描述的是一個資料庫已經排除掉的情況。宣告與約束衝突時，讀的人多半相信宣告，因為它就在眼前，而約束在另一個檔案裡。

收掉連接重複的 DISTINCT

顧客與訂單連起來之後，佳穎出現兩次，因為她有兩張訂單。要一份「下過單的顧客」名單，加 DISTINCT 就對了：

1SELECT DISTINCT 姓名 FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- 佳穎

DISTINCT 宣告「姓名這一欄有重複值」。而顧客表裡佳穎只有一列——重複是連接製造出來的（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。宣告指向了錯的成因，答案卻是對的。

這種宣告落空的代價由下一次修改觸發，而觸發它的動作很小——多要一個欄位就夠：

1SELECT DISTINCT 姓名, 金額 FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
2-- 佳穎 300
3-- 佳穎 500

DISTINCT 作用在整列上，兩列的金額不同，於是它一列都收不掉。上一個人的修法在這裡失效，而失效的理由要回到「重複從哪裡來」這個問題——那個問題當初被 DISTINCT 跳過了。

查證宣告的動作：把關鍵字換成最弱的版本再跑一次

文字本身看不出宣告有沒有兌現——LEFT 寫在那裡，而它保護下來的列可能一列都不剩。差別要現形，得讓 LEFT 這類關鍵字消失一次：把它換成最弱的版本再跑一次，結果變不變就是它有沒有在做事。 這個動作在軟體測試裡叫 mutation testing：在現有資料上結果不變，是那張卡說的突變「存活」；它是不是等價突變（改寫之後行為在任何資料上都相同），要看造不造得出一筆讓改寫前後回不同答案的反例資料（SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 用的名字與造法）。

結果變了的時候，換掉關鍵字這個動作只證明被換掉的那個關鍵字在做事，還沒證明宣告是對的。DISTINCT 那一格就是這種：拿掉之後結果會變，而變的理由是連接把列複製了，與「這一欄有重複值」無關。所以結果變了之後還要問：變化的成因與宣告說的是不是同一件事。

配對已有保證時的 LEFT（〈配對已有保證時的 LEFT JOIN〉那一節）是換掉關鍵字再跑一次這個動作測不出來的：配對由外鍵保證的時候，LEFT 與 JOIN 在現有資料上結果相同，而換掉之後仍然看不出宣告當初有沒有意義。那一種要去查約束，判斷標準是資料庫有沒有替這個配對背書——而約束寫進 schema 也不一定生效，各家在哪一步把寫下與生效分開，在 SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證。

對讀別人查詢的人來說，這個寫下與生效是否一致的差別回答的是「我可以相信這段文字說的話嗎」——而那個問題在讀的當下沒有別的入口。文字該先為哪一個讀者而寫——人還是引擎——是 SQL.21 可讀性與執行代價：兩者一致與分岔的情形 的題目。