換介面重寫一次同樣的邏輯因此是划算的練習：邏輯已經想清楚了，剩下的是查另一套語法怎麼寫。

篩選、連接、分組彙總與視窗函數的兩邊寫法

以下的 emp 兩邊是同一份資料，一邊在 SQLite 裡、一邊在記憶體的 DataFrame 裡。

篩選：挑出符合條件的列

1SELECT name FROM emp WHERE salary > 150

1emp[emp["salary"] > 150][["name"]]

連接：把兩張表按鍵值接起來

1SELECT e.name, d.dname FROM emp e JOIN dept d ON e.dept = d.dept

1emp.merge(dept, on="dept")[["name", "dname"]]

分組彙總：每一組收斂成一列

1SELECT dept, MAX(salary) AS m FROM emp GROUP BY dept

1emp.groupby("dept", as_index=False)["salary"].max().rename(columns={"salary": "m"})

視窗函數：算出分組的統計值並保留原本的每一列

1SELECT name, salary - AVG(salary) OVER (PARTITION BY dept) AS d FROM emp

1emp.assign(d=emp["salary"] - emp.groupby("dept")["salary"].transform("mean"))[["name", "d"]]

transform 是這一組裡最值得記的：它與 agg 的差別正是視窗函數與 GROUP BY 的差別——agg 讓每一組收斂成一列，transform 把組的統計值攤回組內的每一列。

這四組在同一份資料上跑出來的結果逐格相同。

對應斷掉的位置：分組時的空值、索引、順序

有三個地方兩邊的語意本來就不同，照著逐句翻譯會在這裡失準。

空值在分組時的去留。 SQL 的 GROUP BY 把 NULL 當成一組，pandas 的 groupby 預設把分組鍵是缺值的那些列排除掉，於是那一組在結果裡整組消失。

1t.groupby("k").size()                 # {'x': 1}          缺值那一組消失了
2t.groupby("k", dropna=False).size()   # {'x': 1, nan: 2}  與 SQL 一致

同一段邏輯照著翻譯過來，統計結果會少掉一整組而且不會報錯。這是篩選、連接、分組彙總與視窗函數這幾組對應之外最容易靜默出錯的一項。

索引。 DataFrame 的每一列有一個索引，它獨立於欄位存在，而且會在 groupby、merge 之後改變。SQL 沒有對應的概念。翻譯過來的程式碼常常需要 reset_index() 或 as_index=False，那幾個呼叫處理的正是索引這個 SQL 沒有的狀態。

順序。 SQL 的查詢結果在沒有 ORDER BY 時不保證順序。DataFrame 的列有位置順序，而且多數操作會保留它。所以「相同的結果」在順序這一維上兩邊本來就不可比——可比的是集合，而集合的比較要先各自排序才成立。

延伸閱讀：運算發生的位置、ORM 與 DataFrame 的分辨、SQL 的視窗函數與語言設計、pandas 的記憶體邊界

這兩個介面為什麼會分家：一邊把運算交給資料庫，一邊在自己的記憶體裡算。8.2 運算發生的位置 寫這條分界怎麼決定容量上限，以及選邊要問的三個條件。

同一個對比在 SQL 那一側怎麼講：transform 對 agg 的差別就是視窗函數對 GROUP BY 的差別。SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列 用輸出的單位當判斷標準，並示範相鄰的定義漏掉分區之後會跨到別的組上。

從產出認出手上是哪一個介面：8.3 ORM 與 DataFrame 的分辨：回傳值的形狀、連線物件與查詢送出的時機 寫兩者的回傳值形狀差在哪，以及分得開它們的三個訊號。

這套代數在 SQL 那一側怎麼設計：關聯代數的組合規則決定了子句的先後、連接的左右與分組的鍵，而那些規則各有一處與直覺相反。SQL：這個語言為什麼長這樣 從語言的宣告式性質推導這一整組規則，並另外處理文字之外的四方（識別字規則、引擎的寬鬆度、權限、最佳化器）。

換介面之後接手的新限制：SQL 那一側沒有記憶體上限的問題，換到 DataFrame 就有了。8.5 pandas 的記憶體邊界：資料與運算過程的佔用估算，推回資料庫、換引擎與分散式的代價 給估算方法與越過之後的三個方向。

封閉性是它最重要的性質

每個運算的輸入是關係、輸出還是關係，所以運算可以一個接一個組下去，中間結果與來源表的地位相同。這一條買到兩件事：子查詢可以寫在任何接受關係的位置，而多層查詢的判讀方式是逐層看每一層的欄與列。

它也解釋了為什麼外連接的產物可以繼續當下一個連接的輸入——那份補了 NULL 的東西仍然是一個關係。

SQL 與它並非一對一

SQL 在代數之上多了幾樣代數本身沒有的：重複的列（代數的關係是集合，SQL 的表允許重複，所以才需要 DISTINCT）、NULL 與三值邏輯、以及排序。這幾樣正好是最容易讀錯的幾處，理由是它們不受代數的規則保護。

概念位置

SQL 這個分類講語意模型的那幾篇，判斷標準全部收在這一層：子句的先後、連接的左右、條件擺哪一邊、分組的鍵，每一項都是某個運算的組合規則，而不是設計者的偏好。知道規則從代數來，讀不熟的查詢時就有一個可以推的依據，不必靠記憶。

同一套代數換一個介面就是 DataFrame，那也是這兩者多數操作對得上的原因。

往下走

連接產出的新關係怎麼改變列數與空缺，在 SQL.6 連接之後的列數與空缺。同一組操作在 SQL 與 DataFrame 兩個介面上的對應、以及對應斷掉的三個位置，在 python 模組八 8.4。

規則的來源是關聯代數：每一個子句對應一個作用在關係上的運算，而查詢是那些運算的一個組合。代數是來源，語意模型是那套規則本身。

它與另外兩件事分開

與執行方式分開。 最佳化器可以任意重排步驟，只受一個約束：輸出的關係要與語意模型算出來的一致。這個分工是「代價由資料與索引決定、不由寫法決定」的根據（SQL.17 查詢的代價：資料分布、索引與寫法各自的影響）。

與書寫順序分開。 SELECT 寫在最前面而它在求值順序上排在後面，這正是語意模型與文字順序不同的地方（SQL.2 子句的求值順序：每一步可用的欄位、語意模型擋下的寫法與各家引擎放寬的寫法）。

它涵蓋的與它沒涵蓋的

模型定死的那些，換一家引擎不會變：三值邏輯讓條件的答案有第三種、外連接配不上時補 NULL、NOT IN 展開成一串連乘、分組把一組收成一列。三值邏輯、補 NULL 與 NOT IN 的展開在 SQL.6 連接之後的列數與空缺，分組在 SQL.9 分組鍵的選擇：鍵與一組所代表的對象。

模型之外另有幾件事在決定同一段查詢的結果：識別字被摺成什麼樣、引擎接不接受標準禁止的寫法並自己補一個值、送出這段 SQL 的人被允許讀哪些表。識別字在 SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字，引擎自己補值在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機，權限在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限。這幾項與模型的差別是——模型的規則各家一致，這幾項不一致。

概念位置

「符合語意模型」與「答案對了」是兩件事。 模型與約束的分工也在這條線上——約束管資料能長成什麼樣，模型管那批資料算出什麼。 模型保證的是這段文字算出哪一批列，而那批列是不是要問的那個問題的答案，模型不管也管不到——問題不在查詢裡（SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法）。講語意模型的那幾篇反覆出現的安靜錯誤——列數膨脹、外連接被抵銷、空值比較落空——全部發生在模型算對了的前提下。

往下走

規則的來源與封閉性在 Relational Algebra（關聯代數）。模型與書寫順序、執行順序怎麼分開，在 SQL.1 宣告式的紅利與代價。模型之外那幾方各決定什麼，在 Database Engine（資料庫引擎）。

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

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

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

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

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

列數上限省掉去重這一步

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

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

反連接有兩條描述路徑

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

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

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

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

概念位置

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

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

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

往下走

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