它的行為在三個地方與一般的值不同，而三處各自有一組要記的規則。

概念位置

比較：拿 NULL 去比對任何值，答案是第三種——未知。 真、假、未知這三種答案合起來叫三值邏輯，SQL 的每一個條件都在這套邏輯裡求值。 NULL = NULL 的結果既不是真也不是假。而 WHERE 只留下判斷為真的列，所以「未知」與「假」在那一步的下場相同：列被丟掉。判斷有沒有值要用 IS NULL 與 IS NOT NULL，它們問的是位置有沒有值、答案只有真假兩種。

計數：count(*) 數列，count(欄位) 只數那一欄有值的列。 兩者的差額就是空缺的數量。

分組：GROUP BY 把 NULL 當成一個值來分。 所有那一欄是 NULL 的列會收進同一組——這是 NULL 少數表現得像一般值的地方。連接產出的那個 relation 因此可能有一整組列共用同一個空缺。

可觀察訊號與例子

書店的三位顧客裡只有佳穎下過單。LEFT JOIN 之後宗翰與雅文的訂單欄是 NULL，而用等號去找他們回零列且不報錯：

1WHERE 訂單.訂單編號 = NULL     -- 0 列，沒有錯誤訊息
2WHERE 訂單.訂單編號 IS NULL    -- 宗翰、雅文

分組那一側的表現相反。按訂單表的顧客編號分組，宗翰與雅文因為都是 NULL 而被收進同一組——MySQL、SQLite 與 DuckDB 的結果一致。

最難發現的是 NOT IN：子查詢的結果裡只要有一個 NULL，整段查詢回零列而三個引擎都不報錯。推導、實測與 NOT EXISTS 的安全範圍在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯。

設計責任

否定式的成員判斷一律用 NOT EXISTS，除非能保證子查詢那一欄不會有 NULL——而那個保證要來自欄位的約束，不是來自習慣。

那條約束是建表時的一個決定，而它有代價。 允許為空讀起來就是事實的形狀（沒有值就是沒有值），不允許則要替「沒有」發明一個實際的值；兩條在設計當下都合理，而選了前者之後每一段碰到這一欄的查詢都要處理三值邏輯。backend 1.16 Schema 設計決定的查詢代價 的第一節走這個取捨，並給改回來要付的遷移成本。

判斷空缺的來源也要分開。IS NULL 為真時，可能是這一列沒配到對象，也可能是配到了而那個欄位本來就空。兩者在結果裡長得一樣，要靠選對欄位來分——用連接鍵那一欄判斷「有沒有配到」最可靠，因為它在配得上的時候必定有值。

列數變多與多出空缺各自帶來一類錯誤，兩類都不報錯。列數變多帶來的錯誤本篇叫列數膨脹：聚合數的是連接之後的列，回了比實際大的數字。空缺帶來的錯誤本篇叫比較 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 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 拿列數膨脹當例子，說明結果的形狀正確為什麼不構成保證。

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

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

書店的三位顧客裡只有佳穎下過單，兩張都是她的。要找出一張單都沒下的顧客，用 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 的處理。

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

WHERE 那一步發生在算出 兩倍 之前，所以那個名字在那裡還不存在。SQLite 收下同一段，這是它的寬鬆度而不是標準行為（求值順序的完整推導與這條寬鬆度的其他實例在 SQL.2 子句的求值順序：每一步可用的欄位、語意模型擋下的寫法與各家引擎放寬的寫法）。

NULL 在排序結果裡的位置與各家引擎的預設

排序鍵含空值的時候，NULL 與任何值都比不出大小，所以它落在哪一端由引擎自己規定。會同時是排序鍵又可能為空的欄位不少——選填的折扣金額、還沒完成的那些列的完成時間，都是拿來排序的常見對象。下面的表格與查詢把 103 的金額清成 NULL、刪掉 105，留下四列：

1UPDATE 訂單 SET 金額 = NULL WHERE 訂單編號 = 103;
2DELETE FROM 訂單 WHERE 訂單編號 = 105;
3-- 101 是 700、102 是 500、103 是 NULL、104 是 300

三家的規定各自自洽：SQLite 與 MySQL 把 NULL 當成比任何值都小，PostgreSQL 當成比任何值都大，DuckDB v0.10.3 則不論升冪降冪都把 NULL 排在最後——它的預設是 NULLS LAST，不隨 DESC 翻轉。要跨引擎一致就得寫出來，而寫法本身也分兩家：

1SELECT 訂單編號 FROM 訂單 ORDER BY 金額 NULLS LAST;
2-- PostgreSQL 18、SQLite 3.51、DuckDB v0.10.3：104,102,101,103
3-- MySQL 8.4：ERROR 1064 語法錯誤
4
5-- 先排一個布林值：金額是 NULL 的列 (金額 IS NULL) 為真，排在為假的列之後
6SELECT 訂單編號 FROM 訂單 ORDER BY (金額 IS NULL), 金額;
7-- PostgreSQL 18、SQLite 3.51、MySQL 8.4、DuckDB v0.10.3：104,102,101,103

NULL 是比不出大小的那一種值；字串是比得出、而比法由另一條規則決定的那一種。排序鍵換成姓名時，大小寫算不算相同、重音字母排在哪裡，各家預設不同，同一批名字排出來的順序也不同——SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性 用同一批名字在三家上排出三種順序。

本篇要用到這兩層的名字。合法指上一段那三項檢查都通過——判它不必讀任何一列資料，但要知道是哪一家引擎在判：各家收與不收的界線不同，標準禁止的寫法有的引擎照收，而那條界線劃在哪裡、各家怎麼劃，在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機；問對了指算出來的那份關係（欄位固定、由若干列構成的集合，查詢的結果就是一份關係）正好是那個問題的答案，這個詞是本篇為了指認「這批列是不是那個問題的答案」這一層而取的，SQL 的標準術語裡沒有它。

語意模型指這個語言規定的、由查詢的文字算出結果的那套規則，它的每一項規則都有一處與直覺相反（子句的先後、連接的左右、條件擺哪一邊、分組的鍵各是一例）。本篇處理直覺錯掉之後會發生什麼：引擎照樣算完、照樣回一批結果，而那批結果不帶任何出錯的訊號。

正解與錯的寫法：「不等於五」「漏掉星等」與「NOT IN」

書店要找出沒有五星評價的訂單。共用資料裡訂單 101 有一則五星、訂單 102 沒有評價，所以答案是 102。

正確的寫法把星等的條件放進 ON，再挑配不到的那些（SQL.5 ON 與 WHERE：連接條件與篩選條件各自的職責 的「找沒配到的那些列：IS NULL 條件的歸屬」一節）：

1SELECT 訂單.訂單編號 FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5
3WHERE 評價.評價編號 IS NULL;
4-- 102

「不等於五」的錯法把「沒有五星」寫成「星等不等於五」。 其餘不動，只把星等條件挪進 WHERE 並改成不等於：

1... LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
2WHERE 評價.星等 <> 5;
3-- 共用資料：0 列
4--   101 唯一那則評價是五星，5 <> 5 判成假
5--   102 沒有評價，外連接替它補一列、星等是 NULL，NULL <> 5 的真值是未知，WHERE 只留判成真的列
6-- 訂單 101 多一則三星之後：101

這一段問的是「至少有一則非五星評價的訂單」，與「沒有五星評價的訂單」是兩個不同的問題。外連接替配不到評價的訂單補出來、評價欄位全是 NULL 的那一列，MySQL 手冊叫 NULL-complemented row，本篇寫成補出來的列；對補出來的列判不成真的篩選條件叫拒絕 NULL 的條件（null-rejected condition），評價.星等 <> 5 就是一例（NULL 參與比較時為什麼判成未知，在 SQL.6 連接之後的列數與空缺 的「NULL 的比較結果與 IS NULL」一節）。問錯了問題，加上拒絕 NULL 的條件把補出來的列全數濾掉，兩件疊在一起，所以這段查詢回哪些列由資料決定：訂單 101 多一則三星之後，正解仍然是 102，而它交出了恰好相反的那一列。

補一個 IS NULL 讓補出來的列留下也修不掉，它在兩批資料上一次對、一次錯：

1... LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
2WHERE 評價.星等 <> 5 OR 評價.星等 IS NULL;
3-- 共用資料：102，看起來完全正確
4-- 訂單 101 多一則三星之後：101 與 102

補上的只是補出來的列，問題仍然是「至少有一則非五星評價」。

「漏掉星等」的錯法把星等條件整個漏掉，而它在現有資料上回了正確答案。 這一種的星等條件哪裡都沒出現：

1SELECT 訂單.訂單編號 FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
3WHERE 評價.評價編號 IS NULL;
4-- 共用資料：102
5-- 訂單 102 多一則三星評價之後：0 列（正解仍然是 102）

這一段問的是「沒有任何評價的訂單」。它與正解在共用資料上是同一批列，因為有評價的那張訂單剛好只有五星那一則；兩段查詢要到某張訂單的評價全部不是五星時才分開。

「NOT IN」的錯法用 NOT IN 表達否定的成員判斷。 星等條件回到子查詢裡，連接整個省掉：

 1SELECT 訂單編號 FROM 訂單
 2WHERE 訂單編號 NOT IN (SELECT 訂單編號 FROM 評價 WHERE 星等 = 5);
 3-- 共用資料：102
 4-- 評價表多一則訂單編號還沒填的五星評價之後：0 列
 5--   子查詢交出 101 與 NULL，NOT IN 對訂單 102 展開成 102 <> 101 AND 102 <> NULL
 6--   前一項為真、後一項的真值是未知，AND 的結果是未知，WHERE 不留
 7
 8-- 同一個問題寫成 NOT EXISTS，加了那則評價之後仍然回 102
 9SELECT 訂單編號 FROM 訂單
10WHERE NOT EXISTS (SELECT 1 FROM 評價
11                  WHERE 評價.訂單編號 = 訂單.訂單編號 AND 星等 = 5);

NOT IN 展開成一串「不等於」的 AND，子查詢只要交出一個 NULL，那一項對每一列都判成未知，整串因此不會是真（完整推導在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯 的「子查詢含 NULL 時的 NOT IN 與 NOT EXISTS」一節）。NOT EXISTS 逐列問「有沒有一則配得上的五星評價」，訂單編號是 NULL 的那則評價配不上任何一張訂單，所以不影響結果。

答案錯掉的成因分類與引擎不報錯的原因

從要問的那一題到算出來的那批列，中間經過三個環節：提問的人把問題寫成查詢文字、語意模型規定這段文字算出什麼、引擎照它的實作去算。答案錯掉的成因按斷在哪一個環節分類：斷在問題寫成文字的，本篇叫問錯了問題；寫的人對某條規則的預期與語意模型的規定不同，叫誤解語意模型；引擎的行為偏離標準，叫引擎寬鬆；另有一類不斷在任何環節，而是要問的那一題本身還沒成形，叫問題還沒決定。

「不等於五」與「漏掉星等」問錯了問題。「不等於五」問的是「至少有一則非五星評價」，「漏掉星等」問的是「有沒有任何評價」——兩段查詢都精確地回答了它們自己問的那一題，而那一題不是要問的那一題。問錯了問題與模型的規則無關：換引擎、加約束都碰不到它，因為那段文字沒有任何一處是錯的；靜態分析判得出「不等於五」，憑的是它同時誤解了語意模型（見〈「問對了沒有」的判定：靜態分析、約束與反例資料〉）。問題與查詢文字之間還有反方向的落差，SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證 叫它宣告落空：查詢的答案是對的，錯的是文字對下一個讀它的人說的話，例如 LEFT 宣告了一個從未發生的情況。問錯了問題的落差在問題與文字之間，宣告落空在文字與行為之間。

「NOT IN」的錯法誤解語意模型。NOT IN 的展開方式由模型定死，而寫的人預期它表現得像「不在這個集合裡」。誤解語意模型修得掉，改對之後永遠對。分頁是誤解語意模型的另一個實例：同分的列排在哪裡模型沒有規定，而逐頁取的人預期它固定，SQL.12 分頁的排序鍵與接續標記 寫它怎麼變成重複與遺漏。

「不等於五」的錯法同時屬於問錯了問題與誤解語意模型——它問的那個問題不是要問的，而它的星等條件又是拒絕 NULL 的條件、把補出來的列全數濾掉——所以它回的列隨資料變動，這是它比「漏掉星等」與「NOT IN」難診斷的原因。

引擎寬鬆的實例不在這三種錯法裡。引擎接受了標準禁止的寫法並自己補一個值：分組之後把非分組欄放進 SELECT，實例住在 SQL.2 子句的求值順序 與 SQL.9 分組鍵的選擇：鍵與一組所代表的對象，換一家引擎就浮現。SQL.2 除了求值順序，也寫了哪些違反求值順序的寫法會被引擎當場報錯、哪些會被照收——同一個放錯邊的條件在一家報錯、在另一家回一份錯的清單。問題還沒決定的實例是「所有訂單都被評價過的顧客」：它在一張訂單都沒下過的人身上為真（邏輯裡叫空真，vacuous truth），而提問的人多半還沒想過那算不算。問題還沒決定連換誰來寫都不會浮現，因為要問的那一題還沒成形。

這些成因有一個共通的地方：引擎回給寫查詢的人的只有兩樣，錯誤訊息與算出來的那批列，而這些錯誤在兩樣裡都不現形。引擎保證的是兩件事：這段文字合法，而算出來的關係符合語意模型。文字合法與關係符合語意模型這兩項都不決定答案對不對，而答案對不對也不影響這兩項，所以錯誤沒有任何一條經由引擎回報的管道。 三段查詢一則錯誤訊息都沒有，沒有型別衝突，沒有一列長得奇怪。

回來的那批列本身也看不出答案錯了，而看不出來的情形不只一種。「漏掉星等」的錯法在原本那批資料上回了正確答案，看不出問題；「不等於五」與「NOT IN」兩種回零列，而零列既可能是「確實沒有」也可能是條件整段失效——分不出這兩者，正是 SQL.8 IN、EXISTS 與 JOIN 把否定式一律交給 NOT EXISTS 的理由。結果的形狀正確也不構成保證。把訂單接上評價再加總金額：

1SELECT SUM(訂單.金額) FROM 訂單
2LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號;
3-- 共用資料：800（101 是 300、102 是 500）
4-- 替 101 再加一則評價之後：1100
5--   101 配到兩則評價，連接後那張訂單變成兩列，300 算了兩次

兩次回來的都是一列一欄的一個數字，形狀與正確答案沒有任何不同（連接為什麼會複製列，在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

「漏掉星等」的錯法另有一個性質：它在寫下的當時通得過任何檢驗。拿現有資料驗它，答案是對的；逐句讀它，每一個子句都符合語法與模型。

「問對了沒有」的判定：靜態分析、約束與反例資料

「問對了沒有」需要一個答案來比對，而那個答案不在查詢裡，也不在資料裡——它在提問的人手上。所以這一層交不出一條可以機械執行的判定——任何規則都得先知道要問的是什麼，才說得出這批列對不對。

「問對了沒有」這整條判定交不出去，而它底下有幾項較小的判斷交得出去。 一項判斷能不能交給機器，看判斷時要讀的資訊，機器在做這項判斷的那一刻讀不讀得到：引擎收到查詢的時候讀得到查詢的文字與表的結構，資料庫寫入一筆資料的時候讀得到那一筆資料與資料庫當下已有的列，而「要問的是什麼」只有提問的人知道。這些判斷因此按它們要讀什麼分開：只讀查詢文字與表結構的是靜態分析，只讀寫入那一刻資料庫裡的資料的寫成約束，要讀「要問的是什麼」的，機器能接手的只有比對——提問的人先造一筆反例資料、給出它對應的正確答案，機器負責比對查詢回的答案與它是否相同。

靜態分析只讀查詢的文字與表的結構，判斷時不需要任何一列資料，也不需要提問的人。 「不等於五」的錯法是它判得出來的例子：這段查詢寫了外連接，而 WHERE 裡的星等條件是拒絕 NULL 的條件，補出來的列一列都留不住，結果與內連接在任何資料上都相同。這個等價由三值邏輯決定、與資料裡有什麼無關，所以最佳化器規劃查詢時自己就會用到它，MySQL 手冊把這一步叫 outer join simplification。最佳化器做這個改寫時不產生任何警告，要讀執行計畫才看得到：

 1-- 「不等於五」的錯法
 2EXPLAIN
 3SELECT 訂單.訂單編號 FROM 訂單
 4LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號
 5WHERE 評價.星等 <> 5;
 6-- 星等條件拒絕 NULL：補出來的列星等是 NULL，NULL <> 5 判成未知，全數被濾掉
 7-- PostgreSQL 16 印出 Hash Join：最佳化器已經把 LEFT JOIN 改成內連接
 8-- MySQL 8 的 SHOW WARNINGS 印出改寫後的查詢，連接寫的是 join
 9
10-- 正解
11EXPLAIN
12SELECT 訂單.訂單編號 FROM 訂單
13LEFT JOIN 評價 ON 評價.訂單編號 = 訂單.訂單編號 AND 評價.星等 = 5
14WHERE 評價.評價編號 IS NULL;
15-- 星等條件在 ON 裡；WHERE 的 評價編號 IS NULL 對補出來的列判成真，補出來的列留下
16-- PostgreSQL 16 印出 Hash Left Join：外連接保留下來

外連接被最佳化器改成內連接，代表查詢裡的 LEFT 沒有作用，而寫下 LEFT 的人要的正是保留沒有評價的訂單。

「NOT IN」的錯法是另一個例子，靜態分析在它身上判出來的是風險而不是確定的錯。風險由表結構與查詢文字兩處合起來決定，兩處都不必讀任何一列資料：

1-- 表結構：評價表的訂單編號沒有宣告 NOT NULL，這一欄可能是 NULL
2CREATE TABLE 評價 (評價編號 INT, 訂單編號 INT, 星等 INT);
3
4-- 查詢文字：NOT IN 的子查詢讀的正是那一欄
5SELECT 訂單編號 FROM 訂單
6WHERE 訂單編號 NOT IN (SELECT 訂單編號 FROM 評價 WHERE 星等 = 5);
7-- 子查詢只要交出一個 NULL，NOT IN 對每一列都判不成真，整段回零列
8-- 現有資料裡沒有訂單編號未填的評價，所以這段此刻回的仍是 102

靜態分析判不出「漏掉星等」：那段查詢與正解是同一種寫法，只差 ON 少了星等的條件，而查詢文字與表結構裡沒有任何一處說那個條件該在。

約束只讀寫入那一刻資料庫裡的資料，所以資料庫在寫入的那一刻就判得完。 約束是寫進資料庫、由它在每次寫入時檢查的規則，每一種讀的範圍由種類固定：NOT NULL 與 CHECK 只讀正要寫入的那一筆，UNIQUE 讀同一欄已有的值，外鍵讀它指向的那一列。NOT NULL 寫下「這一欄不會缺」，外鍵寫下「這個編號一定指得到一列」。讀的範圍超出這幾種的規則（「評價要在出貨之後」要讀另一張表的出貨日）同樣在寫入那一刻判得完，而要改用觸發器或應用層檢查。「NOT IN」的錯法要評價表裡出現一則訂單編號未填的五星評價才會回零列，而評價表的訂單編號那一欄若帶著 NOT NULL，那則評價一開始就寫不進來——這是「否定式一律用 NOT EXISTS」那條規則的豁免條件，不是對 NOT IN 展開方式那個誤解的修法。「不等於五」與「漏掉星等」寫不成約束：兩者錯在問錯了問題，而判斷一個問題有沒有問對要讀「要問的是什麼」，那不是任何一筆資料的性質。SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證 拿參照完整性把約束走完一輪——外鍵擋下哪些寫入、宣告與生效在哪幾個位置分開，以及內連接掉列與 NOT IN 回零列這兩種錯各由哪一條約束管掉；五種約束各保證什麼在 Constraint（約束）。

要讀「要問的是什麼」的判斷交不出去，而提問的人的判斷可以記成一筆反例資料。 反例資料是一筆讓正解與某個錯的寫法回不同答案的資料，名字取自邏輯裡的反例（counterexample）：兩段查詢在某一筆資料上回的答案不同，就證明兩者不等價。上面三種錯法各有一筆——「不等於五」要訂單 101 再多一則非五星評價，「漏掉星等」要訂單 102 多一則非五星評價，「NOT IN」要一則訂單編號未填的五星評價。

反例資料從表的結構與查詢的條件推得出來，不必先知道哪一種寫法是錯的。 測試領域把這個做法叫等價類劃分（equivalence partitioning）：把輸入按程式對它的行為分類，每一類至少放一筆。落在這段查詢上，等價類是一張訂單配到評價的方式——一則都配不到、配到不只一則、配到的全部不是五星——再加上欄位是空值。沒有宣告約束的表全部允許這些等價類，而寫查詢的人容易當成它們不會發生；正解與錯的寫法對這些等價類的假設不同，所以兩者的答案就在這些等價類上分開。

一份把每個等價類各放進一次的資料，足以讓上面三種寫法各自交出不同的答案：

 1-- 從建好的空表開始；101、102 與 9001 同共用資料
 2INSERT INTO 訂單 VALUES (101,1,'2026-03-02',300), (102,1,'2026-03-09',500),
 3                        (103,2,'2026-03-10',200), (104,2,'2026-03-11',400),
 4                        (105,3,'2026-03-12',600);
 5INSERT INTO 評價 VALUES
 6  (9001,101,5), (9002,101,3),   -- 101：配到不只一則，其中一則五星
 7  (9003,103,3),                 -- 103：配到的全部不是五星
 8  (9004,104,5),                 -- 104：只配到一則五星
 9  (9005,105,4), (9006,105,2),   -- 105：配到不只一則，全部不是五星
10  (9007,NULL,5);                -- 訂單編號是空值的五星評價
11-- 102 一則評價都配不到
12-- 正解：102、103、105
13-- 「不等於五」：101、103、105、105（105 配到兩則非五星評價，出現兩次）
14-- 「漏掉星等」：102
15-- 「NOT IN」：0 列

提問的人要出的仍然只有一件事：這五張訂單裡哪幾張是答案。造得出反例資料，代表提問的人已經把「要問的是什麼」說到分得開兩個問題的程度；造不出來，代表兩段查詢在這張表結構允許的每一種資料上都回同樣的答案，兩種寫法等價、選哪一種都對。反例資料與「問對了沒有」交不出去並不牴觸：反例資料與它對應的正確答案仍然由提問的人給出，交給機器的只有比對這一步。

反例資料與約束改變的對象不同。 約束改變的是資料能長成什麼樣，不改變查詢——加上 NOT NULL 之後「NOT IN」的錯法不再回零列，是因為觸發它的那則評價寫不進來，而那段查詢照樣合法、照樣是同一個誤解，同一個人在下一個可為空的欄位上會再寫一次 NOT IN。反例資料不改變資料庫允許什麼資料，提問的人的判斷也仍然由他給出，改變的是那個判斷的保存形式：反例資料當輸入、他給的答案當預期值，合起來就是一則測試案例，往後每次改動那段查詢都能再跑一次，而讀者多半已經有跑測試案例的工具。反例資料只證偽、不證成——「漏掉星等」的錯法在原本那批資料上通過了一切檢驗，而通過從來不是對的證明。反例資料的射程另有一道邊界：它由提問的人依他當時對問題的理解寫下，所以它分得出「想的對而寫錯了」，分不出「想的就不對」。

反例資料與它的預期答案在測試領域有對應的名字，而測試那邊分得比本篇細：預期值從哪裡取得叫 test oracle，那張卡列了規格、參照實作、人的判斷與現狀四種來源，以及各自抓不到的那些；「寫斷言的人與寫實作的人共用同一份誤解」叫 test provenance；而「造不出反例資料」在 Mutation Testing 裡叫 equivalent mutant。本篇只講這三個概念落在 SQL 查詢上的樣子，三張卡各自涵蓋本篇沒有處理的情境。

正確性之外：查詢的代價與由引擎、資料庫決定的事

本篇之外還有一條與正確性互不覆蓋的軸：同一段查詢要花多久。一段查詢問對了沒有，與它要花多久，各自的判斷標準管不到對方，而代價那一層有一個機械的做法——向引擎要執行計畫。SQL.17 查詢的代價 量的是一道重複值的題目：加一個索引，最慢的那一種寫法就掉到與最快的同一個量級。

本篇處理的錯誤都發生在查詢的文字與提問的人之間：引擎照語意模型把結果算對了，而那不是要問的那一題。一段查詢的結果還受幾件不寫在查詢文字裡的事影響，它們由收下查詢的引擎與資料庫決定。同一段查詢合不合法，由執行它的那一家引擎判定，而標準禁止的寫法有的引擎照收、有的報錯，SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 逐個寫法比較各家收不收、收了之後回什麼。查詢裡的表名與欄名送進引擎之後，引擎會照自己的規則處理大小寫與引號之後再去找對應的表與欄，SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字 寫各家的大小寫規則、引號的作用與保留字。執行查詢的帳號被授予哪些權限、最佳化器選了哪一個執行計畫、表上宣告了哪些約束、字串照哪一套 collation 比較，也各自影響同一段查詢回什麼，分別在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限、SQL.1 宣告式的紅利與代價、SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證 與 SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性。

常見的幾種各自保證不同的事。NOT NULL 保證這一欄永遠有值；UNIQUE 保證這一欄的值不重複；PRIMARY KEY 是前兩者合起來再加上「這是本表辨識一列的依據」；FOREIGN KEY 保證這一欄的值在另一張表裡找得到對應的那一列；CHECK 保證這一欄滿足一個自己寫的條件（例如金額不為負）。

它決定哪些推論可以做

一個判斷標準能不能省掉某一步，取決於約束有沒有把那一步的前提固定住。最直接的一例是空值：NOT IN 在子查詢那一欄出現 NULL 的時候會整個回空集合而不報錯，所以否定式的成員判斷一般用 NOT EXISTS。這條規則有一個豁免——那一欄掛了 NOT NULL。豁免的條件是約束而不是觀察：翻遍現在的資料都沒有 NULL，只證明此刻沒有；約束證明的是往後也不會有，而查詢要活得比這一批資料久。

同一個結構在別處反覆出現：UNIQUE 讓「這個連接會不會讓一列配到多列」變成可以事先回答的問題（見 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯），FOREIGN KEY 讓「這個 JOIN 會不會掉列」有一個不必查資料就成立的答案。

概念位置

約束住在結構那一側，所以它由 DDL 建立與修改，而不是由日常的讀寫語句。這條歸屬有兩個後果：加約束的權限跟建表的權限走在一起，不跟常態運行的帳號走；加約束到一張已經有資料的表上會失敗，如果既有資料裡有違反它的那幾列。

它與索引在外觀上容易混——UNIQUE 在多數引擎底下確實靠一個索引實作，而兩者的責任不同：索引買的是查找速度，約束買的是內容的保證。刪掉一個索引查詢會變慢，刪掉一個約束則是往後的寫入不再被擋。

這條分工有一個邊界：約束宣告的內容同時是最佳化器可用的資訊，所以它買到的有時候多於內容的保證。同一張五千列的表、同一個 EXISTS 查詢、recordDate 上同樣掛著索引，只把索引從 UNIQUE 換成普通索引，SQLite 3.51.0 產出的位元碼就多一圈內層迴圈——唯一的時候引擎知道那次查找至多回一列，不唯一的時候它得準備好再看下一筆。這個差別在 EXPLAIN QUERY PLAN 上看不見，兩邊都印同一行 SEARCH y USING INDEX ix (recordDate=?)，要 EXPLAIN 到位元碼那一層才分得開；而在這組資料上它沒有量出時間差。同一組查詢在 DuckDB 1.5.5 上的計畫與有沒有 UNIQUE 無關。所以約束會不會影響代價是各家自己的決定，不是約束本身的性質（SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機）。

往下走

NULL 在比較、計數與分組裡各自怎麼表現，以及否定式那條規則的完整推導，在 NULL（空值） 與 SQL.6 連接之後的列數與空缺 的「子查詢含 NULL 時的 NOT IN 與 NOT EXISTS」一節。約束能在寫入時擋下哪些會讓答案錯掉的資料、為什麼問錯問題的那一類錯它擋不下，在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法。FOREIGN KEY 擋下哪兩個方向的寫入、同一段宣告在各家引擎為什麼未必生效，在 SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證。約束由誰有權建立、以及它跟常態運行帳號的權限為什麼分開，在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限。