求值順序規定的是每一步能用到哪些欄位與值——而不在這一步能用的欄位與值裡的，那一步就用不了，引擎因此會擋下某些寫法。擋下來的理由分兩種，分法看換一家引擎結果會不會變：這一步確實拿不到那個值的，本篇叫模型層的限制，換哪一家引擎都一樣；照模型拿不到、而有的引擎替使用者補上一個決定的，叫引擎寬鬆，換一家就變。在擋下它的那一家引擎上，模型層的限制與引擎寬鬆的錯誤訊息長得一樣。引擎實際照什麼次序做事是另一種順序（執行順序），由最佳化器決定而不在本篇範圍，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 收下的列條件是一例。

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

引擎把這件事講得很明白，而擋下來的時機分兩種。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 那一步就成立了。