概念位置

計畫是查詢文字與實際代價之間唯一的橋。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 是常見的誤判來源。

與逐步執行的程式對照一次，這個性質最清楚。 用 pandas 或任何一種 DataFrame 寫「找出下過單的顧客」，寫下的是一串動作：先載入這張表、再依條件篩選、再與另一張表合併，每一行都指定了下一步做什麼，而執行就照那個順序發生。SQL 寫下的是一段描述——哪些表參與、配對的條件是什麼、要留下哪些列——至於先讀哪一張、用什麼演算法配對、要不要臨時建索引，一個字都沒說。

紅利是描述與實作脫鉤。一段查詢在一萬列與一億列的資料上都不必改寫，換一台機器、換一個索引配置也不必改寫，因為怎麼算從來就不在寫下的查詢文字裡面。代價是紅利的另一面——怎麼算不在寫的東西裡面，所以從查詢的文字看不出它要花多少。

書寫順序、求值順序與執行順序

書寫順序是子句在文字上的先後：SELECT 在最前面，FROM 跟在後面，WHERE、GROUP BY、HAVING、ORDER BY 依序往下。這個順序是給人讀的，它的作用是讓查詢讀起來像一句話。

求值順序是語意模型規定的先後。它與書寫順序不同：先由 FROM 決定要處理哪個資料集合，再用 WHERE 篩掉列，接著 GROUP BY 分組、HAVING 篩掉組，最後才輪到 SELECT 把要輸出的欄位算出來、ORDER BY 排序。寫在最前面的 SELECT 在語意上排在倒數第二步。

執行順序是引擎實際做的事，由 query optimizer 決定，而最佳化器只受一個約束：輸出的列集合要與語意模型算出來的一致。在這個約束之內，它可以任意重排、可以換演算法、可以臨時建資料結構。

書寫順序、求值順序、執行順序這三者不一致，是宣告式這個選擇本身帶來的。讀查詢時的多數誤判來自把其中兩種當成同一種——最常見的是拿書寫順序去猜執行順序，以為「寫在前面的表會先被讀」。

執行計畫的依據：統計資訊與書寫順序

拿書店的兩張表來看這件事。顧客表五十列，訂單表二十萬列，要數的是兩者配得上的訂單有幾筆。同一個問題寫成兩種順序：

1SELECT count(*) FROM 訂單 JOIN 顧客 ON 訂單.顧客編號 = 顧客.顧客編號;
2SELECT count(*) FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;

兩者都回 200000。看它們的 query plan 要用 EXPLAIN QUERY PLAN（SQLite 的 EXPLAIN 給的是逐行 bytecode，不是計畫），而計畫取決於引擎有沒有這兩張表的統計資訊。

這一節的兩張表可以這樣造：

1CREATE TABLE 顧客 (顧客編號 INT, 姓名 TEXT);
2CREATE TABLE 訂單 (訂單編號 INT, 顧客編號 INT, 金額 INT);
3
4WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i+1 FROM n WHERE i < 50)
5INSERT INTO 顧客 SELECT i, '顧客' || i FROM n;
6
7WITH RECURSIVE n(i) AS (SELECT 1 UNION ALL SELECT i+1 FROM n WHERE i < 200000)
8INSERT INTO 訂單 SELECT i, i % 50 + 1, i % 900 FROM n;

剛建好、還沒統計過的資料庫上，SQLite 給出兩個不同的計畫：

1-- EXPLAIN QUERY PLAN SELECT count(*) FROM 訂單 JOIN 顧客 ON 訂單.顧客編號 = 顧客.顧客編號;
2|--SCAN 訂單
3|--BLOOM FILTER ON 顧客 (顧客編號=?)
4`--SEARCH 顧客 USING AUTOMATIC COVERING INDEX (顧客編號=?)
5
6-- EXPLAIN QUERY PLAN SELECT count(*) FROM 顧客 JOIN 訂單 ON 訂單.顧客編號 = 顧客.顧客編號;
7|--SCAN 顧客
8|--BLOOM FILTER ON 訂單 (顧客編號=?)
9`--SEARCH 訂單 USING AUTOMATIC COVERING INDEX (顧客編號=?)

沒有統計就不知道哪張表大，於是它退回去按查詢文字裡兩張表出現的先後來決定計畫：顧客 JOIN 訂單 那種寫法掃五十列的顧客，為了查找而當場替二十萬列的訂單建一個索引。

跑一次 ANALYZE 讓引擎去數過兩張表之後，同樣兩段查詢得到同一個計畫：

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

兩次都選擇掃二十萬列那張、對五十列那張做查找，寫誰在前面沒有影響。

**書寫順序從來不是引擎的依據，它只是引擎在沒有別的統計資訊時的退路。**真正的依據是統計資訊，而那份資訊不在查詢裡、也不在資料裡，它是引擎另外去數出來存著的資料。

計畫裡還有查詢文字完全沒提到的步驟。AUTOMATIC COVERING INDEX 是 SQLite 當場替顧客表建的索引，BLOOM FILTER 是它加的過濾步驟。查詢裡沒有一個字要求這些。

「先讀的那張表」這個直覺因此對應不到任何固定的一張表——同一段查詢在剛建好、還沒統計過的資料庫上與跑過 ANALYZE 之後，先讀的表不同。文字上的先後只決定語意，不決定執行。它影響語意的位置在外連接：LEFT JOIN 會保留左邊那張表的每一列，配不到對象的也留下、另一側補上空值，所以一張表寫在左邊還是右邊，決定的是哪一張表的列一定會出現在結果裡。多張表相連時「左邊」已經不是一張表——SQL.4 鏈式連接的左運算元 寫那個累積過程，以及在鏈中間放 RIGHT 為什麼會把保護範圍縮到只剩一張表。

求值順序擋下的寫法：聚合函數放進 WHERE

語意模型摸不著，而它會在引擎拒絕的地方現形：把聚合函數寫進 WHERE，SQLite 與 DuckDB 都拒絕，同一件事移到 HAVING 就通過。拿共用資料庫的訂單表找下過一張以上訂單的顧客：

1SELECT 顧客編號 FROM 訂單 WHERE COUNT(*) > 1 GROUP BY 顧客編號;
2-- SQLite：misuse of aggregate: COUNT()
3-- DuckDB：Binder Error: WHERE clause cannot contain aggregates!
4
5SELECT 顧客編號, COUNT(*) AS 張數 FROM 訂單 GROUP BY 顧客編號 HAVING COUNT(*) > 1;
6-- 兩個引擎都回 (1, 2)：顧客編號 1 的佳穎，兩張訂單

兩則訊息都只說了不准，理由要從求值順序讀出來。 WHERE 那一步分組還沒發生，沒有組就沒有組的計數，聚合函數拿不到它要用的那個值；HAVING 排在 GROUP BY 之後，那時每一組的計數已經算得出來。這條限制由語意模型規定，與寫法好不好看無關。

求值順序與執行順序不同的地方在於它是語意模型規定死的，換引擎不變，所以「每一步能用到哪些欄位與值」是一個有固定答案的問題。SQL.2 子句的求值順序 逐步走過求值順序這一串步驟，並分開模型層擋得住的限制與各家引擎自己放寬的——後者包括一種不報錯而給出錯答案的形態。

代價的驗證：輸出與執行計畫各自回答的問題

宣告式把「怎麼算」交給引擎決定，代價也跟著由引擎決定。查詢的文字裡沒有任何一處表示它會掃全表還是走索引、會不會臨時建一個索引、會不會把中間結果寫到磁碟——上面那段計畫證明了這一點，SCAN、BLOOM FILTER 與那個臨時索引，三者一個都不在查詢裡。

所以驗證分成兩件互相獨立的事。結果對不對看輸出，從查詢本身推得出來。代價可不可以接受看計畫，非得問引擎不可，而且同一段查詢在不同資料量、不同索引、不同統計資訊底下的答案不一樣。

開發用的小資料只驗得到結果對不對這一件：資料量小到任何寫法都夠快，所以查詢在開發環境通過，只代表描述得對；代價可不可以接受，要到正式的資料量上才量得出來。

跑 ANALYZE 前後計畫跟著改變的那一組對照，在真實系統上有它的故障形態：統計資訊過時、或者欄位之間的相關性沒有被統計到，最佳化器就拿著錯的資訊選計畫。PostgreSQL Query Optimization 收了這幾種讓計畫選錯的實際案例，以及讀懂 production 計畫要用的 EXPLAIN、EXPLAIN ANALYZE、auto_explain 三層工具。

誰產生它，什麼時候

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

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

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

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

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

它與索引是兩件事

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

概念位置

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

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

往下走

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

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 與索引可用性 用同一批名字在三家上排出三種順序。

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

索引存的是欄位的值與它們對應的列的位置，所以查找要拿一個值進去比對。條件寫成 下單日 = '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 可讀性與執行代價：兩者一致與分岔的情形。

找重複 email 的分組、自連接與 EXISTS 寫法

一張 Person 表，欄位是 id 與 email，要找出重複出現的 email。

用分組。 把列按 email 收成組，問這一組有幾列：

1SELECT email FROM Person GROUP BY email HAVING count(*) > 1;

用自連接。 把表配對，找出 email 相同而 id 不同的兩列（SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接）：

1SELECT DISTINCT p1.email FROM Person p1
2JOIN Person p2 ON p1.email = p2.email AND p1.id <> p2.id;

用 EXISTS。 對每一列問「有沒有另一列 email 跟我一樣」（SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理）：

1SELECT DISTINCT email FROM Person p
2WHERE EXISTS (SELECT 1 FROM Person q WHERE q.email = p.email AND q.id <> p.id);

有無索引時分組、自連接與 EXISTS 的實測時間與計畫

分組、自連接、EXISTS 三種寫法都給出正確答案。以下的時間都在 SQLite 3.51 上量，資料庫沒有跑過 ANALYZE，同一句各跑二十次取最小值。計時器的解析度是一毫秒，量到的時間落在它以下時，下面表格對應的那一格只寫得出「不到 1」。

這一組數字的形狀依賴引擎的存取路徑：SQLite 逐列處理、相關子查詢編成逐列的巢狀執行，所以加一個索引能把下面表格裡 EXISTS 那一格代表的每次查找成本整個換掉。DuckDB 是向量化的引擎——它一次處理一批列而不是一列一列走——處理同一組查詢的方式與 SQLite 不同，三種寫法在它上面的差距形狀也不同。要看的是「代價由資料與可用的存取路徑決定」這個結論，不是下面表格列出的這幾個絕對值。

資料是這樣造的：

1CREATE TABLE Person (id INTEGER PRIMARY KEY, email TEXT);
2
3WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < 4999)
4INSERT INTO Person SELECT i, 'u' || i || '@x.com' FROM n;
5
6WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < 1999)
7INSERT INTO Person SELECT 100000 + i, 'hot@x.com' FROM n;
8
9-- 有索引的那一欄另外跑：CREATE INDEX ix ON Person(email);

七千列，其中一個 email 重複兩千次。同一段查詢在別的機器或別的版本上絕對值會不同，要看的是同一欄之內的相對關係。

沒有索引時最慢的是 EXISTS，有索引時它掉到與分組同一個量級——同一段查詢差了三個量級。分組與自連接兩欄之間沒有這種變化：分組本來就貼著計時器的解析度，加了索引之後量不出來；自連接快了百分之十幾（217 對 186 毫秒）。這個差距小到要先排除雜訊，所以另外重建資料重跑了五輪，每一輪照樣各跑二十次取最小值：五輪都是有索引的那一欄較快，而幅度都遠不到一個量級。三段查詢的文字一個字都沒有改。

計畫說明了 EXISTS 那一格從沒有索引到有索引的時間變化。沒有索引時：

1|--SCAN p
2|--CORRELATED SCALAR SUBQUERY 1
3|  `--SCAN q
4`--USE TEMP B-TREE FOR DISTINCT

CORRELATED 表示那個子查詢引用了外層的欄位，所以它對外層的每一列各執行一次，而每一次都是 SCAN q——掃過整張表。外層那七千列，每一列都讓內層把整張七千列的表掃過一遍。

有索引之後同一段查詢：

1|--SCAN p USING COVERING INDEX ix
2`--CORRELATED SCALAR SUBQUERY 1
3   `--SEARCH q USING COVERING INDEX ix (email=?)

子查詢仍然逐列執行，而每一次從 SCAN（掃全表）變成 SEARCH（透過索引定位）。逐列執行這個結構沒變，變的是每一次的單價。COVERING 的意思寫在 Query Plan（執行計畫） 那張卡；索引本身的代價落在寫入端，這一點寫在 Index（索引） 那張卡。

重複次數改變時分組與自連接的實測

另一組量測換一個變數：五萬列資料，其中一個 email 的重複次數從十次加到兩千次，都沒有索引。三份資料各自這樣造（k 依序是 10、200、2000）：

1CREATE TABLE Person (id INTEGER PRIMARY KEY, email TEXT);
2
3WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < 50000-k-1)
4INSERT INTO Person SELECT i, 'u' || i || '@x.com' FROM n;
5
6WITH RECURSIVE n(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM n WHERE i < k-1)
7INSERT INTO Person SELECT 1000000 + i, 'hot@x.com' FROM n;

分組完全不動。自連接則在重複次數兩千那一列漲了七倍多。

要看的是配對數那一欄。 自連接把每一對重複的 email 實際配出來再靠 DISTINCT 收掉，而配對數是 n(n−1)，隨 n 平方成長——重複次數翻十倍，配對數漲的是一百倍。自連接那一欄的時間沒有跟著漲一百倍，是因為五萬列的掃描本身有一筆固定成本，重複次數還小的時候那筆成本蓋過了配對；等配對數大到四百萬，它才浮上檯面。

分組那一欄不管重複多少次都是同一個值，因為它從頭到尾沒有展開任何配對。分組與自連接在這裡的差別是結構上的，不是調校問題。

寫法影響代價的邊界：條件把索引欄包進函式

本篇的結論有一個邊界，出現在條件把索引欄包進函式的時候。資料沿用〈有無索引時分組、自連接與 EXISTS 的實測時間與計畫〉那一節有索引的七千列：

1EXPLAIN QUERY PLAN SELECT * FROM Person WHERE lower(email) = 'hot@x.com';
2-- `--SCAN Person
3-- 索引 ix 存的是 email 本身，條件問的是 lower() 算完的結果，
4-- 引擎在索引上找不到那個值，只能掃全表、逐列算完再比
5
6EXPLAIN QUERY PLAN SELECT * FROM Person WHERE email = 'hot@x.com';
7-- `--SEARCH Person USING COVERING INDEX ix (email=?)
8-- 條件直接比 email，引擎在索引上查找

兩個條件只在 email 一律以小寫存放時回同一批列——這份資料是，兩段都回兩千列；lower() 那一段另外會配到大小寫寫法不同的 email。這時寫法決定的是引擎能不能用那個索引，而不是它在幾條可行的存取路徑裡挑哪一條——所以它是本篇結論的前提：哪幾條存取路徑可行由條件的形狀決定，挑哪一條才由資料與索引決定。Sargable（可走索引的條件形狀） 給判斷一個條件能不能走索引的標準，以及讓條件走得了索引的改寫方向：把函數條件改寫成範圍（date(下單日) = X 寫成 下單日 >= X AND 下單日 < 次日）、把運算從索引欄移到比較式的另一個運算元上，或者對運算式本身建索引。

比較兩段查詢的快慢：要補上的條件與向引擎要計畫的做法

補上四項再問：資料有多大、分布長什麼樣、有哪些索引、引擎有沒有統計資訊。 最後一項是 SQL.1 宣告式的紅利與代價 實測過的——同一段查詢在跑過 ANALYZE 之前與之後拿到不同的計畫；那一篇也從 SQL 這個語言的性質推了一次，代價為什麼一開始就落在查詢文字之外。

資料量決定像自連接那筆固定掃描成本這種常數項會不會被放大。分布決定會不會踩到某個寫法的最壞情況——上面的自連接就是被重複程度打敗的。索引決定每一次查找的單價，而加索引前後的那組量測裡，索引的有無讓同一段查詢差了三個量級。

資料量、分布與索引都是資料庫當下的狀態，查詢的文字裡讀不到，所以「哪種寫法比較快」是一個要向引擎問的問題，不是比較兩段文字就答得出來的問題。而且要問兩次：一次拿到現在這個狀態下的計畫，一次改動其中一項（加索引、換資料量）之後再拿一次，看它變不變。問一次只拿得到一個狀態下的答案，而加索引前後的那張表證明狀態換了排名就換，重複次數那張表證明分組與自連接的差距會隨資料的分布放大。各家的問法不同，SQLite 是 EXPLAIN QUERY PLAN，PostgreSQL 是 EXPLAIN。本篇的計畫只有三四行，真實系統的計畫有巢狀節點與估計列數，PostgreSQL Query Optimization 給EXPLAIN、EXPLAIN ANALYZE、auto_explain 三層工具的分工，以及四個計畫選錯的 production case：該走索引而走了全表掃描、該用 hash join 而用了 nested loop、缺少多欄位統計而估錯列數、該平行執行而沒有。

代價既然由資料與索引決定，查詢的文字就可以先為讀它的人而寫。SQL.21 可讀性與執行代價：兩者一致與分岔的情形 並排了三組——寫法差異免費的、條件形狀讓兩者分岔的、以及拆開之後在四萬列上快三十多倍的——並給出分岔時該動查詢還是動 schema 的判斷標準。