各個決定的內容、決錯之後的症狀與機制所在的篇章

決錯之後的症狀有一個共同點：查詢照跑而答案不對。 只有兩個決定決錯時會當場出聲：量代價決錯時查詢慢得看得出來；交付時換了引擎，有一類差異第一次執行就報錯。SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 把跨引擎的差異按發聲的位置分級，第一次執行就報錯的叫當場報錯，其餘的差異要麼等某一筆資料才報錯、要麼始終靜默。其餘的決定決錯時欄位正常、列數合理，沒有任何東西提示要去檢查。

最常被跳過的決定：追問需求、設定判斷標準與對邊界

追問需求與設定判斷標準。 這兩個決定發生在打開編輯器之前，所以不留下任何痕跡——跳過了的查詢跟沒跳過的長得一模一樣。而跳過追問需求的代價是整段查詢答錯題，跳過設定判斷標準的代價是後面每一次修改都不知道有沒有改好。

對邊界。 一句需求描述的是資料正常時的樣子，而正式資料裡會出現提出需求的人沒想到、所以沒說的情形。以「哪幾天氣溫比前一天高」為例：同一個測站同一天有兩筆紀錄（感測器重送、補登、換設備之後兩套系統各寫一筆）、觀測日存的是哪一個時區的日期、三個月後才補進來的舊資料讓昨天的答案今天變了、同一個測站代號在某一天之後指向另一個地點。對邊界這個決定，就是在查詢寫好之後把這些情形逐一列出來，並決定每一種出現時查詢該回什麼。

這份清單沒有地方可以查。需求裡沒有它，schema 也只記下有哪些欄位、各是什麼型別，不記下資料在現實中會怎麼偏離預期。列得出幾種，取決於看過多少這個領域的資料：看過感測器重送，才會想到同一天可能有兩筆；看過補登，才會想到歷史答案會變。所以這一步的能力靠經驗累積，每在正式資料上遇到一種新的情形，就把它加進這個領域的查詢的檢查清單。

跳過它的症狀最難察覺：查詢在大部分資料上都對，只在碰到那幾筆特殊資料時算錯，而且不報錯。那幾筆往往要到有人拿結果去對帳，才被發現。

決定的前提：建表時定下的表的形狀

從追問需求到交付，每一個決定都做在一組已經建好的表上，而表的形狀是建表時的決定造出來的：欄位允不允許為空、鍵唯不唯一、長欄位放哪一張表、常一起取的資料切在幾張表、字串的比較規則寫在哪一層、外鍵生不生效。選寫法、補前提的時候，鍵唯不唯一、欄位允不允許為空已經定了；量代價的時候，長欄位放哪一張表、常一起取的資料切在幾張表也已經定了。這些建表時的決定替往後每一段查詢定了價——手上要交的是一份 schema 設計而不是一段查詢時，問題落在追問需求之前。以鍵唯不唯一為例：「哪幾天氣溫比前一天高」用自連接、視窗函數與相關子查詢三種寫法，共同押的前提，是同一個測站同一天只有一筆；表上有 UNIQUE (測站, 觀測日) 時這個前提由資料庫保證，沒有的話每一段查詢都得自己處理重複，否則自連接會把一列配成多列。每一個決定各自替查詢定了什麼代價，實測在 backend 1.16 Schema 設計決定的查詢代價。

在「哪幾天氣溫比前一天高」這句需求上做完全部決定的示範

SQL.22 查詢設計的完整示範：把「哪幾天氣溫比前一天高」從需求做到上線 拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉相隔天數與漏掉分區的兩個錯誤版本：漏掉相隔天數的多報，漏掉分區的錯在哪個方向要看同一天兩個測站誰排在前面；把自連接再分成日期差與等值兩種寫法，在同一組資料上量這兩種自連接、視窗函數與相關子查詢的時間，差到三個量級，其中一種加了索引反而變慢；最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。

與逐步執行的程式對照一次，這個性質最清楚。 用 pandas 或任何一種 DataFrame 寫「找出下過單的顧客」，寫下的是一串動作：先載入這張表、再依條件篩選、再與另一張表合併，每一行都指定了下一步做什麼，而執行就照那個順序發生。SQL 寫下的是一段描述——哪些表參與、配對的條件是什麼、要留下哪些列——至於先讀哪一張、用什麼演算法配對、要不要臨時建索引，一個字都沒說。

紅利是描述與實作脫鉤。一段查詢在一萬列與一億列的資料上都不必改寫，換一台機器、換一個索引配置也不必改寫，因為怎麼算從來就不在寫下的查詢文字裡面。代價是紅利的另一面——怎麼算不在寫的東西裡面，所以從查詢的文字看不出它要花多少。

書寫順序、求值順序與執行順序

書寫順序是子句在文字上的先後：SELECT 在最前面，FROM 跟在後面，WHERE、GROUP BY、HAVING、ORDER BY 依序往下。這個順序是給人讀的，它的作用是讓查詢讀起來像一句話。

求值順序是語意模型規定的先後。它與書寫順序不同：先由 FROM 決定要處理哪個資料集合，再用 WHERE 篩掉列，接著 GROUP BY 分組、HAVING 篩掉組，最後才輪到 SELECT 把要輸出的欄位算出來、ORDER BY 排序。寫在最前面的 SELECT 在語意上排在倒數第二步。

執行順序是引擎實際做的事，由 query optimizer 決定，而最佳化器只受一個約束：輸出的列集合要與語意模型算出來的一致。在這個約束之內，它可以任意重排、可以換演算法、可以臨時建資料結構。

書寫順序、求值順序、執行順序這三者不一致，是宣告式這個選擇本身帶來的。讀查詢時的多數誤判來自把其中兩種當成同一種——最常見的是拿書寫順序去猜執行順序，以為「寫在前面的表會先被讀」。

執行計畫的依據：統計資訊與書寫順序

拿書店的兩張表來看這件事。顧客表五十列，訂單表二十萬列，要數的是兩者配得上的訂單有幾筆。同一個問題寫成兩種順序：

1SELECT count(*) FROM 訂單 JOIN 顧客 ON 訂單.顧客編號 = 顧客.顧客編號;
2SELECT count(*) FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;

兩者都回 200000。看它們的 query plan 要用 EXPLAIN QUERY PLAN（SQLite 的 EXPLAIN 給的是逐行 bytecode，不是計畫），而計畫取決於引擎有沒有這兩張表的統計資訊。

這一節的兩張表可以這樣造：

1CREATE TABLE 顧客 (顧客編號 INT, 姓名 TEXT);
2CREATE TABLE 訂單 (訂單編號 INT, 顧客編號 INT, 金額 INT);
3
4WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i+1 FROM n WHERE i < 50)
5INSERT INTO 顧客 SELECT i, '顧客' || i FROM n;
6
7WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i+1 FROM n WHERE i < 200000)
8INSERT INTO 訂單 SELECT i, i % 50 + 1, i % 900 FROM n;

剛建好、還沒統計過的資料庫上，SQLite 給出兩個不同的計畫：

1-- EXPLAIN QUERY PLAN SELECT count(*) FROM 訂單 JOIN 顧客 ON 訂單.顧客編號 = 顧客.顧客編號;
2|--SCAN 訂單
3|--BLOOM FILTER ON 顧客 (顧客編號=?)
4`--SEARCH 顧客 USING AUTOMATIC COVERING INDEX (顧客編號=?)
5
6-- EXPLAIN QUERY PLAN SELECT count(*) FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
7|--SCAN 顧客
8|--BLOOM FILTER ON 訂單 (顧客編號=?)
9`--SEARCH 訂單 USING AUTOMATIC COVERING INDEX (顧客編號=?)

沒有統計就不知道哪張表大，於是它退回去按查詢文字裡兩張表出現的先後來決定計畫：顧客 JOIN 訂單 那種寫法掃五十列的顧客，為了查找而當場替二十萬列的訂單建一個索引。

跑一次 ANALYZE 讓引擎去數過兩張表之後，同樣兩段查詢得到同一個計畫：

1|--SCAN 訂單
2|--BLOOM FILTER ON 顧客 (顧客編號=?)
3`--SEARCH 顧客 USING AUTOMATIC COVERING INDEX (顧客編號=?)

兩次都選擇掃二十萬列那張、對五十列那張做查找，寫誰在前面沒有影響。

**書寫順序從來不是引擎的依據，它只是引擎在沒有別的統計資訊時的退路。**真正的依據是統計資訊，而那份資訊不在查詢裡、也不在資料裡，它是引擎另外去數出來存著的資料。

計畫裡還有查詢文字完全沒提到的步驟。AUTOMATIC COVERING INDEX 是 SQLite 當場替顧客表建的索引，BLOOM FILTER 是它加的過濾步驟。查詢裡沒有一個字要求這些。

「先讀的那張表」這個直覺因此對應不到任何固定的一張表——同一段查詢在剛建好、還沒統計過的資料庫上與跑過 ANALYZE 之後，先讀的表不同。文字上的先後只決定語意，不決定執行。它影響語意的位置在外連接：LEFT JOIN 會保留左邊那張表的每一列，配不到對象的也留下、另一側補上空值，所以一張表寫在左邊還是右邊，決定的是哪一張表的列一定會出現在結果裡。多張表相連時「左邊」已經不是一張表——SQL.4 鏈式連接的左運算元 寫那個累積過程，以及在鏈中間放 RIGHT 為什麼會把保護範圍縮到只剩一張表。

求值順序擋下的寫法：聚合函數放進 WHERE

語意模型摸不著，而它會在引擎拒絕的地方現形：把聚合函數寫進 WHERE，SQLite 與 DuckDB 都拒絕，同一件事移到 HAVING 就通過。拿共用資料庫的訂單表找下過一張以上訂單的顧客：

1SELECT 顧客編號 FROM 訂單 WHERE COUNT(*) > 1 GROUP BY 顧客編號;
2-- SQLite：misuse of aggregate: COUNT()
3-- DuckDB：Binder Error: WHERE clause cannot contain aggregates!
4
5SELECT 顧客編號, COUNT(*) AS 張數 FROM 訂單 GROUP BY 顧客編號 HAVING COUNT(*) > 1;
6-- 兩個引擎都回 (1, 2)：顧客編號 1 的佳穎，兩張訂單

兩則訊息都只說了不准，理由要從求值順序讀出來。 WHERE 那一步分組還沒發生，沒有組就沒有組的計數，聚合函數拿不到它要用的那個值；HAVING 排在 GROUP BY 之後，那時每一組的計數已經算得出來。這條限制由語意模型規定，與寫法好不好看無關。

求值順序與執行順序不同的地方在於它是語意模型規定死的，換引擎不變，所以「每一步能用到哪些欄位與值」是一個有固定答案的問題。SQL.2 子句的求值順序 逐步走過求值順序這一串步驟，並分開模型層擋得住的限制與各家引擎自己放寬的——後者包括一種不報錯而給出錯答案的形態。

代價的驗證：輸出與執行計畫各自回答的問題

宣告式把「怎麼算」交給引擎決定，代價也跟著由引擎決定。查詢的文字裡沒有任何一處表示它會掃全表還是走索引、會不會臨時建一個索引、會不會把中間結果寫到磁碟——上面那段計畫證明了這一點，SCAN、BLOOM FILTER 與那個臨時索引，三者一個都不在查詢裡。

所以驗證分成兩件互相獨立的事。結果對不對看輸出，從查詢本身推得出來。代價可不可以接受看計畫，非得問引擎不可，而且同一段查詢在不同資料量、不同索引、不同統計資訊底下的答案不一樣。

開發用的小資料只驗得到結果對不對這一件：資料量小到任何寫法都夠快，所以查詢在開發環境通過，只代表描述得對；代價可不可以接受，要到正式的資料量上才量得出來。

跑 ANALYZE 前後計畫跟著改變的那一組對照，在真實系統上有它的故障形態：統計資訊過時、或者欄位之間的相關性沒有被統計到，最佳化器就拿著錯的資訊選計畫。PostgreSQL Query Optimization 收了這幾種讓計畫選錯的實際案例，以及讀懂 production 計畫要用的 EXPLAIN、EXPLAIN ANALYZE、auto_explain 三層工具。

求值順序規定的是每一步能用到哪些欄位與值——而不在這一步能用的欄位與值裡的，那一步就用不了，引擎因此會擋下某些寫法。擋下來的理由分兩種，分法看換一家引擎結果會不會變：這一步確實拿不到那個值的，本篇叫模型層的限制，換哪一家引擎都一樣；照模型拿不到、而有的引擎替使用者補上一個決定的，叫引擎寬鬆，換一家就變。在擋下它的那一家引擎上，模型層的限制與引擎寬鬆的錯誤訊息長得一樣。引擎實際照什麼次序做事是另一種順序（執行順序），由最佳化器決定而不在本篇範圍，SQL.1 宣告式的紅利與代價 把書寫、求值、執行三種順序分開。

求值順序各步驟可用的欄位與值

FROM 走完之後，這一步的中間結果是一個 relation，欄位是來源表的欄位。WHERE 因此只能引用這些欄位，一列一列判斷留不留。本篇把 FROM 當成一個交出關係的整體；多張表的時候它自己是一個過程，按書寫位置逐個把表併進來，SQL.4 鏈式連接的左運算元 寫這個累積怎麼決定每個 ON 引用得到哪些欄位。

GROUP BY 之後中間結果的單位從列換成組，這是整個順序裡變化最大的一步。原本每一列各自獨立，之後每一組是一個單位，而組裡那些列的個別值不再直接可用。

HAVING 篩掉的是組，所以它能用聚合函數——每一組的計數、總和、最大值到這一步都算得出來了。SELECT 到這裡才把要輸出的欄位算出來，別名也是在這一步才誕生。ORDER BY 排的是已經算好的輸出，所以它用得到別名。LIMIT 在最後，它切的是排序完的結果——沒有 ORDER BY 的 LIMIT 取到哪一列沒有保證，因為前面沒有任何一步決定過順序。

模型層的限制：把聚合放進 WHERE

書店有三位顧客，訂單表裡兩張都掛在佳穎名下。要找出下過一張以上訂單的顧客，把「訂單張數大於一」這個條件寫進 WHERE：

1SELECT 顧客編號 FROM 訂單 WHERE COUNT(*) > 1 GROUP BY 顧客編號;

SQLite 回 misuse of aggregate: COUNT()，DuckDB 回 WHERE clause cannot contain aggregates。同一個問題移到 HAVING：

1SELECT 顧客編號, COUNT(*) AS 張數 FROM 訂單 GROUP BY 顧客編號 HAVING COUNT(*) > 1;
2-- 兩個引擎都回 (1, 2)：顧客編號 1 的佳穎，兩張訂單

差別在分組發生了沒有。WHERE 那一步處理的還是一列一列的訂單，「這一組有幾張」這個值在那個時刻還不存在，所以這是模型層的限制而不是功能缺口。這個限制與引擎的寬鬆度（引擎收下不合標準的寫法、自己補上一個決定）無關；寬鬆度在各家怎麼分、差異在什麼位置發聲，在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。

引擎寬鬆：WHERE 用 SELECT 的別名

按求值順序，WHERE 早於 SELECT，別名那時候還沒誕生。標準照這個推論禁止，PostgreSQL 也照這個推論拒絕。

而 SQLite 與 DuckDB 都接受。書店查佳穎這一列，把姓名欄改名之後在 WHERE 用新名字：

1SELECT 姓名 AS 客戶 FROM 顧客 WHERE 客戶 = '佳穎';
2-- SQLite 與 DuckDB 都回 ('佳穎',)；PostgreSQL 報 column "客戶" does not exist

這個放寬的範圍不是照求值順序推出來的。 GROUP BY 與 HAVING 同樣早於 SELECT，而 SQLite 與 DuckDB 在這兩個位置接受別名：

1SELECT substr(下單日,1,7) AS 月份, count(*) AS 張數
2FROM 訂單 GROUP BY 月份;   -- GROUP BY 引用的是 SELECT 那一步才取的別名
3-- SQLite：2026-03 | 2

所以「這一步還沒算到別名」只推得出候選，推不出答案：各家對哪幾個位置放寬、放寬到什麼程度，要各自查。

而放寬是疊在語意模型上面的，沒有取代它。可以從一個細節看出疊的位置：來源表本來就有同名欄位的時候，WHERE 綁的是來源欄位而不是別名。實測用一張只有 x 與 y 兩欄的表，把 y 取名成 x 之後在 WHERE 寫 x = 1：

1CREATE TABLE t (x INT, y INT);
2INSERT INTO t VALUES (1, 2), (2, 1);
3
4SELECT y AS x FROM t WHERE x = 1;
5-- 2

WHERE 綁的若是別名，比對的是 y = 1，會回第二列的 1；實際回的是 2，代表 SQLite 拿來源欄位 x 去比對，DuckDB 也是這樣。來源表沒有同名欄位的時候，引擎才會讓別名接手這個名字。

列的條件放進 HAVING：DuckDB、MySQL 與 SQLite 各自的反應

把聚合放進 WHERE 這種放錯邊，每一家都會擋下來。反過來把列的條件放進 HAVING，後果分兩家，而其中一家不報錯。

這一節要多幾則評價才看得出來，所以換掉共用資料裡那一則，並多加一張訂單 103——換完之後訂單 101 有五星與三星各一則，訂單 102 有兩則五星，訂單 103 有一則三星：

1INSERT INTO 訂單 VALUES (103, 2, '2026-03-20', 400);
2DELETE FROM 評價;
3INSERT INTO 評價 VALUES (1,101,5),(2,101,3),(3,102,5),(4,102,5),(5,103,3);

要問的是「哪些訂單有兩則以上的五星評價」。正確的寫法把星等這個列的條件放 WHERE：

1SELECT 訂單編號, count(*) FROM 評價
2WHERE 星等 = 5 GROUP BY 訂單編號 HAVING count(*) >= 2;
3-- 102 | 2

只有 102，因為 101 的兩則評價裡只有一則是五星。走一遍就看得到為什麼：WHERE 先砍掉三星那兩列，剩下三列拿去分組，組 101 只剩一列而組 102 有兩列，HAVING 再篩掉組 101。

把星等的條件搬進 HAVING：

1SELECT 訂單編號, count(*) FROM 評價
2GROUP BY 訂單編號 HAVING 星等 = 5 AND count(*) >= 2;

DuckDB 拒絕，訊息是 column 星等 must appear in the GROUP BY clause——分組之後組裡有兩個不同的星等，「這一組的星等」沒有定義。MySQL 8 也拒絕，而它擋在更前面的一步：

1ERROR 1054 (42S22): Unknown column '星等' in 'having clause'

MySQL 的 HAVING 只認得分組鍵、聚合，以及 SELECT 裡取好的別名，而 星等 三樣都不是，所以它在解析名字那一步就停了。這一種擋法與設定無關——把 sql_mode 清空再跑，訊息一個字都沒變。

管寬鬆度的那個設定叫 ONLY_FULL_GROUP_BY，從 MySQL 5.7 起是預設值，而它管的是另一個形態：把非分組欄放進 SELECT 的寫法（SELECT 訂單編號, 星等 FROM 評價 GROUP BY 訂單編號）開著時回 ERROR 1055 並在訊息裡點名這個設定，關掉之後就與 SQLite 一樣從組裡任意挑一列。

SQLite 接受，回 101 與 102。 兩張訂單都被報成「有兩則以上五星」，而 101 只有一則。SQLite 從組裡取了其中一列的星等拿去比對，而它取到的剛好是 101 那組裡五星的那一列，於是整組通過。

至於它會取到哪一列，多數時候規格不保證。唯一的例外是同一個 SELECT 裡只有一個 min() 或 max() 的時候——那時 SQLite 保證非分組欄取自那個極值所在的列，這一點有明文規定。除此之外不要依賴它挑中哪一列。

SQLite 收下並給出錯的清單，比 DuckDB 與 MySQL 當場擋下危害更高，因為輸出看起來完全合理。 每組一列、欄位齊全、訂單編號都是實際存在的訂單——沒有任何一處會讓人停下來檢查。放錯邊的那個條件在報錯的引擎上寫的當下就會發現，在寬鬆的引擎上會一路帶著錯的清單走下去。

同一個機制還有一個比較溫和的形態：SELECT 顧客編號, 下單日 FROM 訂單 GROUP BY 顧客編號，DuckDB 同樣拒絕、SQLite 回一個從組裡任意挑的日期。非分組欄放進 SELECT 只讓輸出的值不確定，列的條件放進 HAVING 讓整份清單錯掉。

模型層的限制與引擎寬鬆：分辨的依據與換引擎時的表現

分開模型層的限制與引擎寬鬆的，是引擎手上有沒有一個值可以補上。分組還沒發生的時候，「這一組有幾張」這個值本身還沒有被算出來，引擎沒有值可補，所以聚合放進 WHERE 是模型層的限制。SELECT 那一步還沒算的時候，別名這個名字還沒誕生，而它要指的值早就算好了——差的只是一個稱呼，有些引擎因此願意替使用者把名字對回去。分組之後「這一組的星等」在模型裡沒有定義，而組裡每一列都有自己的星等，SQLite 從中挑一列的值補上。別名放進 WHERE 與列的條件放進 HAVING 都是引擎寬鬆：模型沒給的決定，由引擎替使用者補上。

模型層的限制與引擎寬鬆在換引擎時的表現不同。碰到模型層的限制的寫法，第一次執行就會被擋下來；靠引擎寬鬆跑起來的寫法會安靜跑過，等到換引擎才出現差異——而其中最麻煩的是從組裡任意挑一列的寬鬆：在兩家都寬鬆的引擎之間搬家（SQLite，以及關掉 ONLY_FULL_GROUP_BY 的 MySQL），連報錯都沒有，只是挑到的那一列可能不同。

求值順序在連接上的實例：條件放 ON 還是 WHERE

HAVING 那一節已經露出一個問題：同一個條件擺在哪一步，決定的是留下哪些列，而寬鬆的引擎不會替擺錯的那一種報錯。這個問題在連接上重演一次。ON 是 FROM 那一步內部的條件，WHERE 是下一步，所以條件放 ON 還是 WHERE，是在求值順序的相鄰兩步之間選一步——兩種擺法都合法、都不報錯，而結果差在沒配到的那些列留不留下來。SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 用同一組書店資料把兩種擺法的結果並排，並給一個代進 NULL 就看得出差別的測試。兩種擺法的差別由語意模型規定，SQLite、PostgreSQL 與 MySQL 對同一種擺法回同一批列，所以條件擺錯位置的時候，換一家引擎也不會浮現。在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 按斷在哪一個環節分的成因裡，它屬於誤解語意模型：寫的人預期 WHERE 裡的條件只影響配對，而模型規定它篩的是配對之後的結果。換一家引擎就浮現的是引擎寬鬆，HAVING 那一節 SQLite 收下的列條件是一例。

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

左運算元會累積這件事決定三件事：每個 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.9 分組鍵的選擇：鍵與一組所代表的對象 後面。那一篇的判斷標準是「一組要代表誰」，而選好了鍵之後還有一個問題——組算出來的那個值，要不要跟原本的列擺在一起。

本篇在共用的訂單表上多加兩列，讓兩位顧客各有兩張訂單。共用的那兩列是佳穎（顧客 1）的 101 與 102，下單日 3/02 與 3/09；加的兩列屬於宗翰（顧客 2）：

1INSERT INTO 訂單 VALUES (105,2,'2026-03-05',200), (106,2,'2026-03-20',450);

同一個總額用分組與用視窗函數寫的輸出

「每位顧客的總消費」用分組寫，四列訂單收成兩列：

1SELECT 顧客編號, sum(金額) AS 總額 FROM 訂單 GROUP BY 顧客編號;

11  800
22  650

同一個總額用視窗函數寫，四列訂單仍然是四列，各自帶著自己那位顧客的總額：

1SELECT 訂單編號, 顧客編號, 金額,
2       sum(金額) OVER (PARTITION BY 顧客編號) AS 該顧客總額
3FROM 訂單;

1101  1  300  800
2102  1  500  800
3105  2  200  650
4106  2  450  650

PARTITION BY 承擔的是 GROUP BY 那個鍵的角色——它說明一組由誰構成。差別全在輸出：GROUP BY 那一段的結果只剩兩列，而每一張訂單的金額已經被收進總額裡取不回來了。

明細與組的值同列的計算：訂單佔該顧客消費的比例

分組收掉列之後，訂單這一層的資訊就離開了結果集。要問「這張訂單佔該顧客消費的多少」，需要的是訂單的金額與該顧客的總額同時出現在同一列上：

1SELECT 訂單編號, 金額,
2       round(金額 * 100.0 / sum(金額) OVER (PARTITION BY 顧客編號), 1) AS 佔該顧客百分比
3FROM 訂單;

1101  300  37.5
2102  500  62.5
3105  200  30.8
4106  450  69.2

分組要算出同一份結果，得把同一批資料讀兩次再接起來——一次算總額，一次拿明細去跟它連接：

 1SELECT 訂單.訂單編號, 訂單.金額,
 2       round(訂單.金額 * 100.0 / 各顧客.總額, 1) AS 佔該顧客百分比
 3FROM 訂單
 4JOIN (SELECT 顧客編號, sum(金額) AS 總額      -- 讀第一次：收成每位顧客一列總額
 5      FROM 訂單 GROUP BY 顧客編號) AS 各顧客
 6  ON 各顧客.顧客編號 = 訂單.顧客編號;         -- 讀第二次：每一張訂單接上它那位顧客的總額
 7-- 101 300 37.5
 8-- 102 500 62.5
 9-- 105 200 30.8
10-- 106 450 69.2（與視窗函數那一段的結果相同）

視窗函數把這兩次寫成一次，明細與組的值在同一趟裡就都算出來。這裡說的是結構省了一次連接，不是它一定跑得比較快：兩者的代價差多少由資料量、分組數與可用的索引決定，而那要向引擎要計畫——SQL.17 查詢的代價 量了同一道題三種寫法在有無索引下的排名對調。

選用分組或視窗函數的依據：結果的一列代表什麼

判斷標準是一句話：結果的一列代表什麼。 一列代表一位顧客，用 GROUP BY；一列代表一張訂單而順便帶著顧客層的值，用視窗函數。

這一句對得上 SQL.9 分組鍵的選擇：鍵與一組所代表的對象 的鍵判斷標準，鍵的判斷標準決定一組由誰構成，輸出單位決定這一組收不收成一列；一段用到分組或視窗函數的查詢，兩者都要先回答。

後續的子句跟著這個選擇走。GROUP BY 算出來的值可以放進 HAVING 篩組（SQL.2 子句的求值順序：每一步可用的欄位、語意模型擋下的寫法與各家引擎放寬的寫法），而視窗函數算出來的值到 SELECT 那一步才誕生，WHERE 與 HAVING 都拿不到它——要拿它當條件，得把整段包成一層子查詢再從外面篩（部分引擎另有 QUALIFY 這個子句直接做這件事，標準 SQL 沒有）。算 佔該顧客百分比 的那段查詢要篩出「超過五成」的訂單時寫成這樣：

 1-- 直接在同一層寫 WHERE 佔該顧客百分比 > 50，SQLite 3.51 拒絕：
 2--   misuse of aliased window function 佔該顧客百分比
 3SELECT 訂單編號, 佔該顧客百分比 FROM (
 4  SELECT 訂單編號,
 5         round(金額 * 100.0 / sum(金額) OVER (PARTITION BY 顧客編號), 1) AS 佔該顧客百分比
 6  FROM 訂單
 7)                                -- 內層算完視窗函數，佔該顧客百分比成為一個普通欄位
 8WHERE 佔該顧客百分比 > 50;       -- 外層的 WHERE 讀得到它
 9-- 102 62.5
10-- 106 69.2

LAG 與 LEAD：取同一組裡相鄰的列

明細列還在，於是「同一位顧客的上一張訂單」這個概念才存在——分組把明細收掉之後，能取的相鄰只剩組與組之間的。所以視窗函數除了對整組算值，還能直接取同一組裡相鄰的某一列。LAG 往前取、LEAD 往後取，而相鄰的定義由 ORDER BY 給：

1SELECT 訂單編號, 顧客編號, 金額,
2       金額 - LAG(金額) OVER (PARTITION BY 顧客編號 ORDER BY 下單日) AS 與上一張的差額
3FROM 訂單;

1101  1  300  （空）
2102  1  500  200
3105  2  200  （空）
4106  2  450  250

每一位顧客的第一張訂單前面沒有列可取，值是 NULL。取同一組裡相鄰一列的問題用自連接也寫得出來，差別在自連接要把兩列配起來，而 LAG 沿著已經排好的順序直接往前數一列。SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接 走的是配起來那條路，並給了配對會不會膨脹這個條件。

排序相鄰與問題要的相鄰：分區、排序鍵與距離條件

LAG 交出的是排序相鄰——照 ORDER BY 排好之後緊鄰的那一列，而問題要的相鄰往往是另一種：同一位顧客的上一張、前一天、上一個月。排序相鄰與問題要的相鄰對不上的時候，查詢照樣回結果。

把上面那段的 PARTITION BY 拿掉，其餘不動。少了分區之後 LAG 沿全表的下單日排序。兩個版本並排在同一段查詢裡：

1SELECT 訂單編號, 顧客編號,
2       金額 - LAG(金額) OVER (ORDER BY 下單日) AS 沒分區的差額,                       -- 沿全表的下單日往前取一列
3       金額 - LAG(金額) OVER (PARTITION BY 顧客編號 ORDER BY 下單日) AS 分區後的差額   -- 只在同一位顧客之內往前取
4FROM 訂單
5ORDER BY 下單日;                  -- 列序照全表的下單日：3/02、3/05、3/09、3/20

1訂單  顧客  沒分區的差額   分區後的差額
2101   1     （空）         （空）
3105   2     -100           （空）
4102   1     300            200
5106   2     -50            250

非首列的三列全部錯了。宗翰的第一張訂單拿佳穎的訂單當「上一張」算出 -100，佳穎的第二張拿宗翰的算出 300。這些數字沒有一個報錯，而它們都是拿兩位不同顧客的訂單相減得來的。

排序相鄰與問題要的相鄰對不上，除了跨到另一位顧客，也會發生在時間上：ORDER BY 下單日 排出來的相鄰兩列，日期上可能隔了半個月。問題若要的是「比前一天高」，那就要另外寫一個距離條件，因為排序只保證先後、不保證間隔。

那個條件的形狀是把距離也算成一欄，再從外面篩：

1SELECT 訂單編號 FROM (
2  SELECT 訂單編號, 金額,
3         LAG(金額) OVER w AS 前一筆,
4         julianday(下單日) - julianday(LAG(下單日) OVER w) AS 相隔天數
5  FROM 訂單 WINDOW w AS (PARTITION BY 顧客編號 ORDER BY 下單日)
6)
7WHERE 金額 > 前一筆 AND 相隔天數 = 1;
8-- 本篇的四列訂單：零列（102 與佳穎的上一張相隔 7 天，106 與宗翰的上一張相隔 15 天）
9-- 拿掉 AND 相隔天數 = 1：102、106

少了距離條件，102 與 106 都會被當成「前一天」的比較。

這個缺口在逐日資料上更難察覺。逐日觀測只要偶爾缺一天，少了距離檢查的版本就會把斷點兩側當成相鄰而多算幾十次比較，而多出來的量相對於總列數小到不會有任何一處顯得異常——查詢照跑，結果集的規模也看不出差別。

所以 OVER 括號裡有三件事要分開確認：PARTITION BY 說明相鄰限定在哪個範圍之內，ORDER BY 說明沿著什麼排，而那個排序鍵要能把同一組裡的列排成唯一的次序。 排序唯一最容易漏——排序鍵有並列時「前一列」是哪一列沒有定義，同一組資料與同一個窗規格因此可以給出不同的答案，而同一段 SELECT 裡另有一個排序不同的視窗就足以讓它換一個：

 1-- 本篇的四列訂單再加一張與 102 同一天下單的 107（只在這一段成立）
 2INSERT INTO 訂單 VALUES (107,1,'2026-03-09',100);
 3
 4SELECT 訂單編號, LAG(訂單編號) OVER (PARTITION BY 顧客編號 ORDER BY 下單日) AS 上一張
 5FROM 訂單;
 6-- 102 的上一張是 101，107 的上一張是 102
 7
 8SELECT 訂單編號, LAG(訂單編號) OVER (PARTITION BY 顧客編號 ORDER BY 下單日) AS 上一張,
 9       row_number() OVER (ORDER BY 金額) AS 金額名次   -- 多一個按金額排序的視窗；上一張那一欄的寫法沒動
10FROM 訂單;
11-- 107 的上一張變成 101，102 的上一張變成 107（SQLite 3.51）

並列時要補一個決勝的次鍵：窗規格寫成 ORDER BY 下單日, 訂單編號 之後，兩段查詢的上一張那一欄都是 102 接在 101 後面、107 接在 102 後面。分區、排序鍵與排序唯一都確認之後，還要問排序相鄰是不是就等於問題要的相鄰——答案是否定的時候，那個距離條件得自己補上。

OVER 括號裡的分區與排序作為宣告

PARTITION BY 顧客編號 宣告的是「相鄰限定在同一位顧客之內」。寫了它而它沒在做事也是可能的——每位顧客都只有一張單的時候，拿掉它結果不變，那一類「宣告在、行為不需要它」的情形在 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證。漏寫它則是另一回事：文字裡沒有那份宣告，錯的是答案。上一節的兩個缺口（漏分區、漏距離條件）共同的形狀是查詢照跑、結果集的規模也看不出差別，SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 把輸出不帶訊號的幾種形態並排：回了正確答案的、回零列的、以及列數與欄位都看不出異常的。

1-- MySQL 8.4
2CREATE TABLE t (id INT PRIMARY KEY, k INT);
3INSERT INTO t VALUES (1, 30), (2, 10), (3, 20);
4
5SELECT group_concat(id) FROM (SELECT id FROM t ORDER BY k) d;
6-- 1,2,3    主鍵序；衍生表裡的 ORDER BY k 被丟掉了
7SELECT id FROM (SELECT id, k FROM t) d ORDER BY k;
8-- 2、3、1  ORDER BY 寫在最外層才照 k 排

這個語言用一套規則決定哪些列會出現在結果裡（那套規則叫語意模型），而輸出的順序是它管得最少的一項：規則只到「排序鍵分得出高下」為止，分不出高下的那些它沒有規定。

本篇交代順序從哪裡來、ORDER BY 看得到什麼、以及比不出大小的值落在哪一端。ORDER BY 沒有規定同分的列誰先誰後，這件事在什麼時候變成錯誤，在 SQL.12 分頁的排序鍵與接續標記——整批看的時候同分的列換位置沒有後果，每一頁各查一次的時候它變成重複與遺漏；那一篇寫排序鍵要補到兩兩可分的判斷標準，以及把接續標記（cursor）從位置換成值的寫法。

本篇範圍之外的兩件事各有專篇。哪些列會進到這份結果由條件與連接決定，順序管不到那一層：條件擺哪一邊決定留下哪些列在 SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責，連接怎麼改變列數在 SQL.6 連接之後的列數與空缺。視窗函數的 OVER (ORDER BY ...) 是另一個順序，它決定計算時誰算相鄰、不決定輸出怎麼排，兩者可以不同，SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列 的〈排序相鄰與問題要的相鄰：分區、排序鍵與距離條件〉一節寫那一種。

本篇的查詢跑在共用資料庫的訂單表上，並把 101 的金額改成 700、再加三張，讓五張訂單裡有三張同樣是 500 元：

1UPDATE 訂單 SET 金額 = 700 WHERE 訂單編號 = 101;
2INSERT INTO 訂單 VALUES (103, 2, '2026-03-10', 500), (104, 2, '2026-03-11', 300),
3                        (105, 3, '2026-03-12', 500);
4-- 101 是 700 元，102、103、105 是 500 元，104 是 300 元

沒有 ORDER BY 時列序的來源

同一段查詢，同一批資料，中間只多建了一個索引：

1-- SQLite 3.51
2SELECT 訂單編號 FROM 訂單 WHERE 金額 >= 300;
3-- 101,102,103,104,105    計畫：SCAN 訂單
4
5CREATE INDEX ix ON 訂單(金額);
6
7SELECT 訂單編號 FROM 訂單 WHERE 金額 >= 300;
8-- 104,102,103,105,101    計畫：SEARCH 訂單 USING INDEX ix (金額>?)
9--   索引照金額排：300 的 104、500 的三張（102、103、105）、700 的 101

查詢的文字一個字都沒改，回來的順序整個換掉了。沒有索引的那一次照資料存放的先後走，建了索引的那一次照索引上的先後走——兩種都正確，因為那份關係本來就沒有規定過順序。

這件事在開發時多半看不見。一張小表、一種計畫，看到的順序穩定得像是有保證，而讓它變動的條件（建了索引、資料長大、統計更新、換一家引擎）沒有一項在查詢的文字裡。

ORDER BY 在求值順序裡的位置與它用得到的別名

ORDER BY 排的是 SELECT 已經算完的那份結果，所以 SELECT 裡取的別名它用得到：

1SELECT 金額 * 2 AS 兩倍 FROM 訂單 ORDER BY 兩倍 DESC;
2-- 三家都接受：1400、1000、1000、1000、600
3
4SELECT 金額 * 2 AS 兩倍 FROM 訂單 WHERE 兩倍 > 1000;
5-- PostgreSQL：column "兩倍" does not exist
6-- MySQL：ERROR 1054 Unknown column '兩倍' in 'where clause'
7-- SQLite：收下，回 1400