這個詞值得單獨認一次，因為中文的「關係」在日常語言裡指人或事物之間的聯繫，與這裡的意思無關。它是 relation 的譯名，指的是那個集合本身。

概念位置

把中間結果也當成關係，多層查詢才讀得動。 書店的 FROM 顧客 LEFT JOIN 訂單 走完之後，得到的那一份有姓名與訂單編號兩種欄位、四列（佳穎兩列、宗翰與雅文各一列而訂單編號是 NULL）。它沒有對應的資料表，沒有名字，也不會被寫進磁碟——而後續的 WHERE、GROUP BY 全部對它操作，不對原本那兩張表操作。

這個性質讓查詢可以層層套疊：一個連接的輸出可以當下一個連接的輸入，子查詢的輸出可以當外層的來源。也因為每一層的輸入與輸出都是同一種結構，query optimizer 才有重排的空間——只要最後產出的關係一樣，中間怎麼組合都合法。

Outer join 是這組運算裡的一個，它產出的關係比來源表多了補 NULL 的那些列。

可觀察訊號與例子

判斷現在處理的是不是還是原表，看列數與欄位。連接之後列數可能變多（一列配到多列就複製一次）、欄位是兩邊合起來的、還可能出現來源表裡沒有的空缺。三者任一成立就表示已經離開原表了。

設計責任

多層查詢的判讀方式是逐層檢查每一層的欄位與列，而不是想像最後那一張表。把每個 JOIN 都想成「兩張表配對」在第三張表之後就失準，因為那時左邊已經是前兩層累積出來的關係。

概念位置

計畫是查詢文字與實際代價之間唯一的橋。SQL 只描述要什麼結果，所以掃全表或走索引、雜湊連接或巢狀迴圈這些決定都不在查詢的文字裡，要問引擎才知道。連接的兩種演算法差在做法：巢狀迴圈對左邊的每一列去右邊找一次，雜湊連接先把一邊建成雜湊表再逐列去查它。連接要保護哪一側是查詢說了算（見 outer join），而用什麼演算法達成它由計畫決定。

同一段查詢的計畫會隨資料量、索引與統計資訊改變，所以計畫是某個時間點某個資料庫狀態下的答案，不是查詢本身的屬性。

可觀察訊號與例子

書店把顧客與訂單連起來，EXPLAIN QUERY PLAN 在 SQLite 上回三行（查的是 FROM 訂單 JOIN 顧客，訂單二十萬列、顧客五十列）：

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

SCAN 與 SEARCH 是兩種取法：SCAN 訂單 表示二十萬列的訂單表逐列看過，SEARCH 顧客 表示對五十列的顧客表透過索引定位而不逐列看。

AUTOMATIC 指的是這個索引不存在於資料庫裡，是引擎為了這一次查詢臨時建的——它判斷建索引比全表掃描划算。COVERING 指的是索引本身帶著查詢要的欄位，所以定位之後不必再回去讀原本的列。BLOOM FILTER 是它加的一道快速排除步驟。

這三行裡沒有一個字出現在原本的查詢裡。 查詢只說了要把兩張表按顧客編號連起來，其餘全部是引擎的決定——而它們決定了這段查詢要花多久。

同一段查詢在別的資料庫狀態下會得到別的計畫——有沒有統計、有沒有索引都會換掉它。上面那三行對書寫順序也敏感：把兩張表對調寫成 FROM 顧客 JOIN 訂單，沒有統計的資料庫會改成掃顧客那張，跑過 ANALYZE 之後才收斂回上面這一個。所以讀計畫要連同「當時的資料庫是什麼狀態」一起讀，那組對照在 SQL.1 宣告式的紅利與代價：書寫、求值與執行順序各自由誰決定 與 SQL.17 查詢的代價：資料分布、索引與寫法各自的影響。

DuckDB 的 EXPLAIN 換一種呈現，回一棵運算子樹，節點標著 HASH_JOIN、SEQ_SCAN 這類名稱與估計的列數；EXPLAIN ANALYZE 另外附上實際跑出來的列數與耗時。

設計責任

估計值與實際值差很多的時候，先懷疑統計資訊而不是查詢的寫法——最佳化器是照估計值選的，估計錯了選擇就跟著錯。判讀計畫要對照當時的資料量，把在小資料上量到的計畫套到 production 是常見的誤判來源。

它比較的依據是另外存著的一份統計資訊——那份摘要既不在查詢的文字裡也不在資料表裡，而統計多新，它的估計就多準。

概念位置

最佳化器的存在是 SQL 宣告式性質的直接結果。查詢只描述要什麼結果，所以「怎麼算」這個決定必須有人做，而做這個決定的就是它。

它的選擇依據是估計的代價，而估計來自統計資訊——每張表大概多少列、某個欄位的值大概怎麼分布。所以它的判斷品質取決於那些統計有多新，與查詢寫得多好無關。它的產物是一份 query plan，而樹上每個節點處理的都是一個 relation。

可觀察訊號與例子

書店的顧客表五十列、訂單表二十萬列。同一個連接寫成 FROM 訂單 JOIN 顧客 與 FROM 顧客 JOIN 訂單，在跑過 ANALYZE 的資料庫上 SQLite 兩次回報一模一樣的計畫——都掃二十萬列那張、對五十列那張做查找。書寫位置決定語意，執行方式由最佳化器另外決定。

統計缺席時它只好照文字的順序掃——那一組對照的完整實驗在 SQL.1 宣告式的紅利與代價：書寫、求值與執行順序各自由誰決定。

換掉可用的資源，計畫也會變。建好 訂單(顧客編號) 索引之後，同一段查詢從三行縮成兩行——SCAN 顧客 接 SEARCH 訂單 USING COVERING INDEX ix，臨時索引不必再建。

它也可以做等價變換，例如把某些 outer join 轉成內連接，前提是查詢的其他部分已經讓外連接補的那些列不可能出現在結果裡。

設計責任

查詢沒動而某天變慢時，變的是統計而不是查詢——最佳化器照估計值選，估計舊了選擇就跟著舊。所以這種情形的歸因起點是統計資訊的新舊，不是查詢的寫法。

反過來，最佳化器選錯而統計是新的時候，才輪到用提示或改寫去引導它，而那些手段會把原本自動適應資料變化的查詢釘死在一個選擇上。

書店有三位顧客——佳穎下過兩張訂單、宗翰與雅文一張都沒下。要一份「每位顧客與他的訂單」的名單，用內連接得到：

1佳穎  101
2佳穎  102

宗翰與雅文不在名單上。他們沒有訂單可以配對，於是內連接把他們整個丟掉了。換成 LEFT JOIN：

1佳穎  101
2佳穎  102
3宗翰  NULL
4雅文  NULL

這就是「保護」的意思：左邊那張表的每一列都留著，右邊配不上的欄位補 NULL。而「哪些顧客一張單都沒下」這個問題，答案正是那兩列補 NULL 的——內連接會讓它無從回答。

三種寫法差在保護哪一側：LEFT 保護左運算元，RIGHT 保護右運算元，FULL 兩側都保護。

概念位置

外連接產出的仍然是一個 relation，所以它可以繼續當下一個連接的輸入，而 query optimizer 在特定條件下可以把它降級成內連接——前提是查詢的其他部分已經讓補 NULL 的那些列不可能出現在結果裡。

補上的 NULL 是這個機制的產物，與資料裡本來就有的空值來源不同。這一點決定了後續怎麼判斷：IS NULL 問的可能是「這一列沒配到」，也可能是「配到了而那個欄位本來就空」。

可觀察訊號與例子

保護會被 WHERE 抵銷。上面那個 LEFT JOIN 加上 WHERE 訂單.金額 > 100 之後，宗翰與雅文那兩列的金額是 NULL、答不出「大於 100」，於是被篩掉，結果與內連接相同。

外連接寫了卻拿到內連接的結果，多半就是這件事：WHERE 裡引用了右表的欄位。判斷保不保得住的方法是把補 NULL 的那一列代進條件裡：判成真才留得下來。IS NULL 判成真所以保住，IS NOT NULL 判成假所以取消——兩者看起來成對而落在相反的一側。而反查「沒配到的那些」要挑一個不可為空的欄位（通常是連接鍵）來問 IS NULL，用可為空的欄位會把「配到了而那個欄位本來就空」的列一起挑進來。

設計責任

要在保留左側全部列的前提下限制右側的配對範圍，條件寫進 ON；要從成品裡篩，條件寫進 WHERE。兩者在內連接底下同值，所以這個差別只在外連接現形。

鏈式查詢裡混用 LEFT 與 RIGHT 會讓保護的方向中途反轉。RIGHT 的右運算元通常只是一張表，而左運算元是前面累積出來的全部，所以保護範圍與多數人的本意相反。把需要保護的表移到最前面、其餘一律 LEFT，方向就一致了。

沒有索引時，找出某個條件成立的列要把整張表看過一遍。有索引時，引擎先在索引裡定位，再回頭取那些列。

索引建了而引擎不走它有兩個常見的成因。一個是統計資訊沒更新——索引決定有沒有一條快的路，統計決定引擎知不知道該走那一條。另一個是條件把索引欄位包進了函式或運算裡，那時引擎沒有可以拿去比對的值，Sargable 那張卡寫這個形狀怎麼判、怎麼改。

概念位置

索引是查詢代價的主要變數之一，而它不出現在查詢的文字裡。同一段 SQL 在有索引與沒索引的資料庫上執行方式完全不同，結果卻一模一樣——這正是宣告式語言的分工：查詢說要什麼，索引與計畫決定怎麼拿。

它的代價落在寫入端。每一次新增、修改或刪除，相關的索引都要跟著更新，所以索引不是加越多越好。同一個 relation 上建了多個索引，讀取變快而寫入變慢。

可觀察訊號與例子

SQLite 的計畫用 SCAN 與 SEARCH 分開兩種取法：SCAN 訂單 表示整張表逐列看過，SEARCH 顧客 USING AUTOMATIC COVERING INDEX 表示透過索引定位。

計畫裡那幾個關鍵字（AUTOMATIC、COVERING、BLOOM FILTER）各指什麼，在 query plan。

設計責任

索引由查詢的形狀決定，不由表的形狀決定。要建哪些索引取決於實際會執行哪些查詢，所以它是在知道查詢模式之後才做得準的決定。

複合索引的欄位順序有影響：(顧客編號, 下單日) 這個索引對「先按顧客再按日期」的查找有用，對「只按日期」的查找幫助有限。順序要對齊查詢的條件形狀。

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

概念位置

比較：拿 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 為真時，可能是這一列沒配到對象，也可能是配到了而那個欄位本來就空。兩者在結果裡長得一樣，要靠選對欄位來分——用連接鍵那一欄判斷「有沒有配到」最可靠，因為它在配得上的時候必定有值。

概念位置

「一組」是由 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 是例外：它們對重複不敏感，複製幾次結果都一樣。

概念位置

獨立子查詢與外層無關，可以整段剪下來單獨執行。它算一次，把結果交給外層。WHERE 顧客編號 IN (SELECT 顧客編號 FROM 訂單) 裡的括號就是這一種——訂單表那一份清單先算好，外層再拿它比對。

相關子查詢引用了外層的欄位，離開外層就跑不動。它對外層的每一列各執行一次。WHERE EXISTS (SELECT 1 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號) 是這一種——括號裡的 顧客.顧客編號 來自外層，所以每一位顧客各問一次。

讀陌生查詢時這是一個可以直接看的訊號：括號裡出現外層的表名，它就是逐列被問一次的。兩種子查詢交出的都是值而不是一個 relation，這一點決定了下一節那個錯誤訊息。

可觀察訊號與例子

子查詢交出的是值，不是表。SELECT 姓名, 訂單.金額 FROM 顧客 WHERE 顧客編號 IN (SELECT ... FROM 訂單) 會回 no such column: 訂單.金額——訂單這張表沒有進到外層的 FROM 裡。

要帶欄位出來有另一條路：把相關子查詢寫在 SELECT 裡，SELECT 姓名, (SELECT 金額 FROM 訂單 WHERE 訂單.顧客編號 = 顧客.顧客編號 ORDER BY 訂單編號 LIMIT 1) FROM 顧客。它一次只交得出一個值，所以要多欄或多列時仍然回到連接。

設計責任

相關子查詢的逐列執行在沒有索引時代價很高——外層每一列都讓內層掃一次全表。有索引之後每一次從掃全表變成定位，同一段查詢可以差幾百倍。

獨立子查詢有另一個陷阱：它的結果裡出現任何一個 NULL，外層的 NOT IN 就整段失效而不報錯。推導與實測在 SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯。

這個字有另一個常見的所指——「表結構」，也就是有哪些表、每張表有哪些欄位、型別與約束是什麼。 兩者不同層：命名空間是容器，表結構是被裝的東西。談 schema migration 的時候用的是後者，談 permission denied for schema public 的時候用的是前者。

概念位置

分層在錯誤訊息上看得出來。一個角色被拒絕讀某張表，訊息是 permission denied for table 顧客；同一個角色被拒絕建新表，訊息是 permission denied for schema public——擋的位置不同，要授的權也不同。被擋住的那些物件裡最常見的是表，而表是一種 relation。

PostgreSQL 15 之後 public schema 預設不再開放給所有人建立物件，在那之前這個操作會成功。同一段 SQL 在不同版本上的結果因此不同，而差別在預設值不在語法。

可觀察訊號與例子

information_schema 本身就是一個 schema，裡面裝著描述其他物件的視圖。查自己有哪些授權用的 information_schema.role_table_grants 就是「schema 名.表名」這個兩段式的寫法。

不是每個資料庫都有這一層。SQLite 沒有 schema 也沒有使用者，整個資料庫是一個檔案，存取由檔案系統決定。

設計責任

看到這個字先判它在哪一層。判斷方法是看它旁邊的動詞：跟「建立物件」「授權」「限定名稱」一起出現的是命名空間；跟「欄位」「型別」「遷移」「版本」一起出現的是表結構。

兩者在部署上也分工：命名空間常用來把不同租戶或不同應用的物件隔開，而表結構的演進是另一組問題——雙寫、回填、切流與回滾，那些在 backend 模組一的資料庫轉換實作。

誰產生它，什麼時候

多數引擎用一道明確的指令收集：SQLite 與 PostgreSQL 都是 ANALYZE，PostgreSQL 另有 autovacuum 在背景定期重收。剛建好的資料庫沒有統計，剛大量寫入之後統計是舊的。

沒有統計的時候引擎不會拒絕執行，它退回去用別的線索。SQLite 在這種情形下照查詢文字裡表出現的先後決定計畫——書寫順序在這裡才有影響力，而那是引擎沒有別的資訊時的退路，不是它的依據。跑過 ANALYZE 之後同樣兩種寫法得到同一個計畫。

它決定的是估計，不是事實

最佳化器比較的是估計代價，而估計來自這份摘要。所以判斷品質取決於統計有多新，與查詢寫得多好無關：

• 查詢沒動而某天變慢，變的通常是統計而不是寫法——歸因的起點放在統計的新舊
• 計畫上的估計列數與實際列數差很多，先懷疑統計，再懷疑寫法
• 在小資料上量到的計畫套到 production 常常對不上，因為兩邊的統計不同

它與索引是兩件事

索引決定引擎有沒有一條快的存取路徑可以走，統計決定它知不知道該走那一條。索引建了而統計沒更新的時候，最佳化器可能估錯而不走它——兩者要一起看。

概念位置

統計資訊是「查詢的文字不足以決定執行方式」這件事的具體內容。查詢說要什麼結果，query optimizer 決定怎麼拿，而它決定的依據既不在查詢裡也不在資料裡——它在這一份另外存著的摘要上。

這讓同一段 SQL 沒有固定的執行方式：資料沒變、索引沒變、查詢沒變，只要統計重收過一次，query plan 就可能不同。所以「這段查詢的計畫是什麼」這個問題要連同資料庫的狀態一起問。

往下走

有無統計的兩個計畫並排、以及書寫順序為什麼只是退路，在 SQL.1 宣告式的紅利與代價。統計、索引與資料分布三者各自決定代價的哪一部分，在 SQL.17 查詢的代價。

這條線在權限上有實際後果

兩類的授權是分開的，而它們在日常運行裡的頻率差很多：應用程式跑起來之後幾乎只做 DML，DDL 只在部署或遷移的時候用一次。這讓最小權限有一個明確的切法——常態運行的帳號不給 DDL，遷移用另一個帳號。

代價的形狀也不同。一句 DML 寫錯影響的是那些列，可以用另一句 DML 補回來；一句 DDL 寫錯（DROP TABLE 那一類）拿掉的是結構，補救要靠備份。

兩類的擋法不在同一層

DML 的權限掛在表上——GRANT SELECT ON 顧客。DDL 的權限多數掛在更上面一層：能不能建新表由 schema 那一層決定，不是由某一張表決定，因為建的時候那張表還不存在。

概念位置

這條線切的是語句改動的對象，而 SQL 的其餘概念多數只活在 DML 這一側——relation、外連接、分組、子查詢 全部是在既有結構上取資料的方式。DDL 決定那個結構長什麼樣，它跑完之後才輪到那些概念。

兩類在時間上的分布因此完全不同：DDL 集中在部署那幾分鐘，DML 散在系統活著的每一秒。權限、備份策略與事故的補救方式都跟著這條線分。

往下走

授權的單位與最小權限的具體切法在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限。DDL 權限實際被用到的場合（雙寫、回填、切流、回滾）在 資料庫轉換實作。

三個分開的地方

列有沒有順序。 DataFrame 的列從頭到尾有一個位置，可以問「第三列是什麼」。關係沒有順序這個屬性，SELECT 回來的列要靠 ORDER BY 才排得出來。

誰在算。 對 DataFrame 的每一個操作在自己的行程裡執行，資料先整批進記憶體；對關係的操作交給資料庫引擎，程式收到的只有結果。上限因此不同——一邊是這台機器的記憶體，一邊是資料庫的儲存。

寫下的是動作還是描述。 DataFrame 的程式碼是一串照順序發生的動作：載入、篩選、合併。SQL 寫下的是要什麼結果，怎麼算由引擎決定。這一條是 SQL 這個分類每一篇的起點。

概念位置

DataFrame 在 SQL 那個分類裡的角色是對照組。宣告式這個性質單獨看不出形狀，跟一段逐步執行的程式並排才清楚——同一件事，一邊每一行指定下一步做什麼，一邊只描述要什麼。

兩邊的底層是同一套 關聯代數，所以多數操作對得上；對不上的地方正好落在上面那三項差別上。

往下走

宣告式與逐步執行的完整對照、以及三種順序的分工，在 SQL.1 宣告式的紅利與代價。同一組操作在兩種介面上的四組對應與對應斷掉的三個位置，在 python 模組八 8.4。

封閉性是它最重要的性質

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

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

SQL 與它並非一對一

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

概念位置

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

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

往下走

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

常見的幾種各自保證不同的事。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 的授權單位與最小權限。

引擎要先有一個具體的值可以比對

索引存的是欄位的值與它們對應的列的位置，所以查找要拿一個值進去比對。條件寫成 下單日 = '2024-03-01' 時那個值就在條件裡。

條件寫成 date(下單日) = '2024-03-01' 時，索引存著 下單日 的值而條件問的是 date() 算完的結果，兩者對不起來。引擎要把每一列的 下單日 取出來各算一次才知道答不答得上，而那就是掃過整張表。同一張表、同一個索引，五萬列：

1-- SQLite 3.51，訂單表五萬列（訂單編號 / 顧客編號 / 下單日 / 金額）
2-- CREATE INDEX ix_日 ON 訂單(下單日)，查的是 SELECT *
3下單日 = '2024-03-01'          SEARCH 訂單 USING INDEX ix_日 (下單日=?)
4date(下單日) = '2024-03-01'    SCAN 訂單

這個形狀能排除，確認要看計畫

索引欄位被包進函式或運算裡的時候，那個索引走不了查找（引擎仍可能把它整個掃過去當成一份較窄的資料來源，計畫上是 SCAN ... USING COVERING INDEX），這一步照字面就判得出來：問那個欄位在條件裡是裸著的還是被包住的。上面那兩行取的是 SELECT *，索引蓋不住它才印成 SCAN 訂單；同一組條件換成只取索引欄與主鍵，兩行都會多出 COVERING。除非另外對同一個運算式建了索引——那時走的是另一個索引，對運算式本身建索引那一條路寫的就是它。

裸著則不保證走得了。同一張表上有幾種裸欄位的條件照樣掃全表：開頭是萬用字元的比對（LIKE '%03-01'）、OR 接上另一個沒有索引的欄位、以及 LIKE '2024-03%' 這種前綴比對。最後一種有兩條出路：SQLite 打開 case_sensitive_like 之後它自己就走得了，或者手動拆成 >= 與 < 的範圍。實測五萬列上，原本的 LIKE '2024-03%' 掃全表而拆成範圍之後走索引查找，兩者回同一批列。

所以形狀是排除法的一步，答案仍然要向引擎要計畫。要不到計畫的時候，看條件的形狀是僅剩能做的那一步——它只看條件的文字，不需要連線、不需要看資料，也不需要建立任何物件的權限（SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限）。

被包住與本來就裸著這兩種命中，能動的位置不同。被包住的（函式包住、運算搬得動）改寫條件本身就能讓它走索引，下一節那三條解決的都是同一件事——把索引欄位還原成裸的，或者換一個索引來配合它。三條的代價並不相同：拆成範圍要讀的人自己拼邊界，運算搬邊與運算式索引不動原本的讀法，而運算式索引把代價換到寫入端（哪一條先試在 SQL.21 可讀性與執行代價：兩者一致與分岔的情形）。

本來就裸著而仍然掃全表的，差別在那個條件描不描得出索引上的一段連續區間。前綴比對描得出，所以它換成範圍之後走得了；萬用字元開頭要比對的值散在索引的各處，OR 接無索引欄則有一半根本不在索引裡。這兩種改寫條件本身幫不上忙，剩下的變數在統計與選擇性上。

同一個問題換一個形狀

date() 那個條件要的是某一天，而同一件事可以用範圍表達，兩端都是具體的值：

1下單日 >= '2024-03-01' AND 下單日 < '2024-04-01'
2    SEARCH 訂單 USING INDEX ix_日 (下單日>? AND 下單日<?)

把運算搬到不含索引欄位的那一邊也成立：下單日 = date('2024-03-15','-14 day') 的右邊先算成一個值，左邊仍然裸著，計畫走查找。

條件本身改不動的時候，還有一個方向是讓索引去配合條件——對運算式本身建索引。CREATE INDEX ix_月 ON 訂單(substr(下單日,1,7)) 之後，原本掃全表的 substr(下單日,1,7) = '2024-03' 變成 SEARCH 訂單 USING INDEX ix_月 (<expr>=?)。它的代價同樣落在寫入端，而且比一般索引多一項：每次寫入要多算一次那個運算式。

與統計資訊是兩個成因

索引建了而引擎不走它有兩個常見的成因，處置不同。統計資訊過舊時引擎估錯代價、判斷它不划算，那時條件的形狀本來就走得了，重收統計就會改；條件把欄位包住時引擎沒有路可走，統計再新也一樣，那時要改的是查詢。

兩者分得開，是因為形狀決定引擎有沒有路可走、統計只決定它想不想走。把條件換成裸欄位的形狀之後計畫跟著變，代表原本擋住的是路；計畫沒變，代表路一直都在而引擎判斷它不划算。

概念位置

SQL.17 查詢的代價：資料分布、索引與寫法各自的影響 的結論是代價由資料與索引決定、不由寫法決定，而這張卡是那個結論有界的例外。邊界很窄：寫法在這裡決定的是引擎能不能用那個索引，而最佳化器在幾條可走的路裡挑哪一條仍然由資料與統計決定。

往下走

索引本身是什麼、代價為什麼落在寫入端，在 Index（索引）。SCAN 與 SEARCH 這些字怎麼讀，在 Query Plan（執行計畫）。同一段查詢的排名隨索引與資料分布重排的實測，在 SQL.17 查詢的代價。好讀的寫法與走得了索引的寫法分岔時該動哪一層，在 SQL.21 可讀性與執行代價：兩者一致與分岔的情形。

SQL 寫成 CROSS JOIN，也可以在 FROM 裡用逗號把兩張表隔開。

條件決定它會不會被展開

代數說連接從積開始，而那是語意層的定義，執行方式由最佳化器按代價選。條件把兩邊綁起來的時候，它用索引或雜湊直接找出配得上的那些列，全部組合一次都沒有被造出來。

條件缺席的時候展開才會發生。一張逐日的觀測表跟自己做沒有條件的 CROSS JOIN：

1CREATE TABLE Weather (id INTEGER PRIMARY KEY, recordDate TEXT, temperature INT);
2WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < 3890)
3INSERT INTO Weather SELECT i, date('2015-01-01', i || ' day'), i % 40 FROM n;
4CREATE UNIQUE INDEX ix ON Weather(recordDate);

1-- SQLite 3.51，Weather 表 3891 列
2SELECT count(*) FROM Weather a CROSS JOIN Weather b;
3-- 15139881
4
5|--SCAN a USING COVERING INDEX ix
6`--SCAN b USING COVERING INDEX ix

15139881 是 3891 的平方。外層每掃一列，內層就把整張表再走一遍，而這一千五百萬對配對在後面的子句拿到資料之前就要先產生出來。這張表加到 13891 列之後，列數變成 3.6 倍而配對數變成 192959881——將近十三倍。成長是平方而非線性，這正是這個運算與其他多出來的列的差別。

要看的是條件把不把兩邊綁起來，而不是用了哪個關鍵字。 CROSS JOIN 加一個等值條件，與 JOIN ... ON 寫同一個條件，對引擎是同一段查詢（SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證）；反過來，JOIN 寫了而 ON 的條件只提到單邊的欄位，展開照樣發生。

與列數膨脹是兩種不同的多

結果比預期多的時候有兩個成因，分辨它們決定要改什麼。

列數膨脹是條件正確而一列配到了多列，於是它被複製那麼多次——多出來的量由資料的重複程度決定，改法是把展開的那一層先收成一列，或改用不展開的寫法。笛卡兒積是條件從一開始就沒有把兩邊綁住——多出來的量由兩張表各自的大小決定，改法是補上那個條件。

分辨的問句落在條件上而非結果上：這個條件把一列綁到對面幾列。 綁到常數量級（幾列、幾十列）是配對條件，多出來的量由重複程度決定，那是膨脹；綁到與表的大小同量級，那個條件篩掉了一些列，而每一列對面掛著的對象數仍然隨表一起長，多出來的量由兩張表的大小決定，那是積。

「有沒有同時引用兩邊」不足以分辨。ON a.v > b.v 同時引用了兩邊，而它把左邊每一列綁到右邊將近一半——v 的值互不相同時，一千列得 499500 對、兩千列得 1999000 對，仍然是平方。低基數的等值鍵同理：ON a.區域 = b.區域 只有幾個區域時，一千列對一千列得五十萬對。

這裡刻意不問「這一列是靠哪個條件配起來的」——JOIN 寫了而 ON 只提單邊欄位的那個形態，讀者答得出「靠那個 ON 條件」而它並沒有把兩邊配起來，問句會把積判成膨脹。

概念位置

笛卡兒積是連接的下限——條件寫得越少，結果越靠近它，而條件寫滿的時候結果落在兩張表配得上的那些列。所以「連接的結果集會不會整個換一個量級」這個問題等於「條件綁住了多少」，與用了 JOIN 還是 CROSS JOIN 無關。而條件綁不綁得住，由它引用到幾個表的出現決定——與那個分辨問句是同一件事。

它在關聯代數裡的位置說明了漏寫連接條件的後果為什麼這麼大：查詢退回它的定義起點，全部組合重新成立。這是結果集大小的整個量級換掉，與逐步變慢是不同的一件事。

往下走

條件正確而列數仍然變多的那一種，在 SQL.6 連接之後的列數與空缺。同一批配對用自連接與 EXISTS 兩種寫法的實測對照，在 SQL.17 查詢的代價。條件只用來判斷存在時結果的上限落在哪裡，在 Semi-join 與 Anti-join（半連接與反連接）。CROSS JOIN 這個關鍵字對讀的人宣告了什麼，在 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證。production 查詢的結果集大小怎麼治理，在 Cardinality Explosion。

本分類反覆說「引擎」在做某件事，說的都是同一件事——差別在它做的是哪一種決定，而那決定了換一家引擎會不會得到不同的結果。

它的四種決定，換引擎的後果各不相同

接不接受這段文字。 引擎檢查名字解析得到、型別配得上、子句的組合合乎規則。標準定死的那些各家一致；標準禁止而各家自行放寬的那些不一致，於是同一段查詢在一家報錯、在另一家跑得動（SQL.2 子句的求值順序：每一步可用的欄位、語意模型擋下的寫法與各家引擎放寬的寫法 與 SQL.9 分組鍵的選擇：鍵與一組所代表的對象 各有一個實例）。

名字指向哪個物件。 沒加引號的識別字被摺成什麼樣由引擎決定，各家的規則不同（SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字）。

要花多久。 這由最佳化器決定，而它受一個約束：輸出的列集合要與語意模型算出來的一致。所以換引擎會換掉代價，不換掉答案（SQL.17 查詢的代價：資料分布、索引與寫法各自的影響）。

回哪一批列。 這一項由關聯代數的組合規則定死，各家一致。三值邏輯、外連接補 NULL、NOT IN 的展開方式都在這一層，所以那幾類錯誤換引擎不會消失（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。

概念位置

引擎是「文字之外」那幾方裡射程最大的一方——識別字規則、寬鬆度與設定、最佳化器都住在它裡面，而權限系統是它另外管的一層（SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限）。所以「換一家引擎」這句話涵蓋的變動比它聽起來的多。

引擎不決定的只有一件事：這批列是不是那個問題的答案。那一層沒有機械判定，理由在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法。

錯誤訊息的措辭由引擎決定而且會隨版本改，所以各篇引的那些字串是對照用的——判讀看它拒絕了什麼，不看它怎麼說。

往下走

各家在同一段查詢上的分歧最集中的地方，在 SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字。挑執行方式的那個元件在 Query Optimizer（查詢最佳化器），它產出的那份計畫在 Query Plan（執行計畫）。它另外存著的那份摘要在 Query Statistics（統計資訊）。

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

它與另外兩件事分開

與執行方式分開。 最佳化器可以任意重排步驟，只受一個約束：輸出的關係要與語意模型算出來的一致。這個分工是「代價由資料與索引決定、不由寫法決定」的根據（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（資料庫引擎）。

「基數」這個譯名在站內還有另外三個所指。 資料建模那一側說的是兩張表之間的關係屬於一對一、一對多還是多對多；查詢結果那一側說的是一段查詢回幾列（Cardinality Explosion）；監控那一側說的是一個指標有幾種標籤組合。本卡與最佳化器讀的都是上一段那個計數義，其餘幾個只是共用一個譯名。

選擇率是一個條件留下多少比例的列。它是條件的屬性而非欄位的屬性：狀態 = '已完成' 與 狀態 = '已取消' 寫在同一欄上，而兩者的選擇率可以差一個量級以上——下一節那組資料裡是十八倍。

兩者在等值條件上有一個關係：值分布均勻的時候，欄 = 某值 的選擇率大約是相異值個數的倒數。分布不均勻的時候這個估算失準，而那正是統計資訊要另外記下最常出現的幾個值的原因。

同一個索引，最佳化器對不同的值做相反的決定

二十萬列的訂單表，狀態 只有兩個值（已完成佔九成五、已取消佔半成），顧客編號 有五萬個值。兩欄各建一個索引，跑過 ANALYZE（收集統計的那道指令）之後問同一種等值條件：

1-- PostgreSQL 18
2SELECT 備註 FROM 訂單 WHERE 狀態 = '已完成';     -- Seq Scan（索引沒被用）
3SELECT 備註 FROM 訂單 WHERE 狀態 = '已取消';     -- Index Scan using ix狀態
4SELECT 備註 FROM 訂單 WHERE 顧客編號 = 12345;    -- Index Scan using ix顧客

同一個 ix狀態，同一種條件形狀，兩個值得到相反的決定。走索引要先讀索引拿到位置、再回原表取 備註 這一欄，每一列付兩次；命中九成五的列時，這筆帳輸給從頭讀一遍。

引擎的依據寫在統計裡，而那份摘要是看得到的：

1SELECT attname, n_distinct, most_common_freqs FROM pg_stats WHERE tablename = '訂單';
2 狀態     |       2    | {0.94996667,0.050033335}
3 顧客編號 | -0.25113   |

n_distinct 是基數，most_common_freqs 是那幾個值各自的選擇率。這兩欄是抽樣估出來的，每跑一次 ANALYZE 都會在小數後幾位變動——真值是 0.95 與 0.05，而印出來的從來不是整數。顧客編號 那一格的負數是另一種寫法——絕對值小於一時代表「相異值個數是總列數的這個比例」，0.25 乘二十萬約等於五萬。

這兩個數是估計而不是事實。 它們來自上一次收集統計的那一刻，所以同一段查詢在資料變動之後可能換一個計畫，而查詢的文字一個字都沒改（Query Statistics）。

同一份統計，各家的取捨不同

上面那組表搬到 SQLite 3.51，ANALYZE 跑過之後三段查詢全部走索引，包含命中九成五的那一段。SQLite 的 sqlite_stat1 記下的數字與 PostgreSQL 量到的是同一件事：

1訂單 / ix狀態 → 200000 100000     -- 二十萬列，每個相異值平均十萬列
2訂單 / ix顧客 → 200000 4          -- 二十萬列，每個相異值平均四列

所以「基數低的欄位上索引沒用」這句話要分兩半聽：低基數確實讓多數值的選擇率變高，而要不要因此放棄索引是最佳化器的判斷，各家的門檻不同。可攜的說法是選擇率，不是計畫。

概念位置

這兩關的成本模型建在一個前提上：資料按列存放，而索引是另一份按鍵排好的結構，走它要回原表取其餘欄位。 欄式引擎（DuckDB、以及讀 parquet 這一類）不是這個形狀——它按欄讀、靠區塊的最大最小值跳過整段，沒有逐列回表那筆帳，所以「命中九成五就別走索引」在那裡不成立，對應的手段是資料的排序與分區。下面兩關針對的是前一種。

選擇率與 sargable 是索引派不派得上用場的兩個獨立條件。sargable 問的是條件的形狀能不能翻成索引上的一次查找——欄位被函式包住就翻不了。這一關過不了不等於索引沒用：條件裡用到的欄位都在索引上的時候，引擎仍然可能整個掃過索引再逐列過濾，省下的是回原表那筆帳（PostgreSQL 印成 Index Only Scan 加一個 Filter，SQLite 印成 SCAN ... USING COVERING INDEX）。所以兩關管的是不同的索引用法，而不是同一種用法的兩道閘。選擇率問的是通過查找之後還剩多少列——形狀對而留下的列佔了大半，最佳化器仍然會選擇不走它。兩關都過，索引才換得到速度。

基數也決定連接之後的列數。低基數的欄位當連接鍵時，一列會配到對面同一個值的所有列，而那個數量隨表一起長——這是笛卡兒積那張卡分辨「積」與「膨脹」時用的同一個量。

往下走

這兩個數怎麼被收集、多久失效一次，在 Query Statistics（統計資訊）。query optimizer 拿它們估代價的過程，以及估錯時計畫長什麼樣，在 Query Plan（執行計畫）。同一道題三種寫法的排名怎麼隨索引重排，在 SQL.17 查詢的代價。production 上結果集大小怎麼治理，在 Cardinality Explosion。

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 查詢的代價。