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

概念位置

「一組」是由 GROUP BY 的鍵決定的，所以聚合要等到分組發生之後才有意義。 這解釋了一個看起來像限制的行為：聚合寫進 WHERE 會被拒絕，因為那一步分組還沒發生，沒有組就沒有組的計數。同一件事寫進 HAVING 通過，因為那一步分組已經完成。

沒有 GROUP BY 的時候整張表算一組，所以 SELECT count(*) FROM 訂單 回一列。分組之後結果的單位從列換成組，而每一組仍然是一個 relation 的子集。

可觀察訊號與例子

count(*) 與 count(欄位) 數的不是同一件事：前者數列，後者只數那一欄有值的列。書店的兩張訂單接上評價之後有三列，而其中一列的星等是空的，於是 count(*) 回 3、count(評價.星等) 回 2。差額就是空缺的數量（見 NULL）。

設計責任

連接之後做聚合，算的是連接結果的列，不是來源表的列。 一列配到多列就被複製一次，所以 count 會多、sum 會重複加。

處理方式依聚合的性質分兩類。可加的（count、sum）可以用 count(DISTINCT 鍵) 把單位拉回來，或先把展開的那一層各自彙總成一列再接上去。不可加的（avg、中位數、百分位）兩條路都不通——先彙總再平均會變成平均的平均，權重錯了。這一類要把分子與分母一起帶出來（子查詢裡同時算 sum 與 count，接上來之後再相除）。

max 與 min 是例外：它們對重複不敏感，複製幾次結果都一樣。

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

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

書店的三位顧客裡只有佳穎下過單，兩張都是她的。要找出一張單都沒下的顧客，用 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 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 把輸出不帶訊號的幾種形態並排：回了正確答案的、回零列的、以及列數與欄位都看不出異常的。