查詢的文字之外，還有幾方決定一段 SQL 最後做什麼：識別字規則、權限、最佳化器、約束、collation，以及引擎寬鬆度——標準禁止的寫法這一家引擎收不收（寬鬆度那一方在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機）。識別字規則是離查詢文字最近的那一方：名字還沒指到任何一張表之前，引擎就已經按這套規則把它改寫過一次。同一張表被誰允許讀寫是另一方的事，在 SQL.16 SQL 的權限模型：角色、GRANT 的授權單位與最小權限；最佳化器那一方，執行順序怎麼從書寫順序分出來在 SQL.1 宣告式的紅利與代價。

這與命名慣例是兩件事。取什麼名字是設計問題，Schema Design 的「Naming 與一致性」段 給表、欄、外鍵、布林、時間戳、索引各自的慣例，以及縮寫不一致、隱性意義這幾種反模式；這裡談的是取好的名字送進引擎會發生什麼。改寫的後果在單一引擎上看不見，換一個引擎才浮現：一段建表語句在原本那個引擎上建好了表，同樣的名字搬到另一個引擎去查卻找不到——名字在送進引擎的路上會先被改寫一次，而兩個引擎改寫的規則不一樣。

PostgreSQL 的大小寫摺疊與引號

在 PostgreSQL 上建一張大小寫混合的表，名字加了引號：

1CREATE TABLE "Orders" ("OrderId" INT);
2SELECT * FROM Orders;
3-- ERROR: relation "orders" does not exist

錯誤訊息把發生的事直接印出來了：查詢裡寫的是 Orders，而引擎去找的是 orders。沒加引號的識別字一律被摺成小寫，之後才拿去比對。

反過來也成立。建表時不加引號，存進去的就是摺過的版本：

1CREATE TABLE MixedCase (x INT);
2-- 實際存進系統目錄的表名是 mixedcase

所以建表與查詢兩邊只要都經過同一道摺疊，名字就對得上：

1-- PostgreSQL，兩組各在一個空的資料庫上跑
2CREATE TABLE MixedCase (x INT);     -- 存成 mixedcase
3SELECT * FROM mixedcase;            -- 找得到
4
5CREATE TABLE "MixedCase" (x INT);   -- 加了引號，存成 MixedCase
6SELECT * FROM MixedCase;            -- 摺成 mixedcase 去找
7-- ERROR: relation "mixedcase" does not exist

加引號的效果是關掉「沒加引號就摺成小寫」這道摺疊，要求逐字比對。

這道摺疊只作用在名字上。同一家引擎把 Orders 摺成 orders 之後，拿 'Anna' 去比 'anna' 時用的是另一套規則，叫 collation，而 PostgreSQL 預設的 collation 判這兩個值不相等——值的大小寫與名字的大小寫由兩套彼此獨立的規則管。SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性 寫 collation 這套規則住在哪一層，以及索引與條件的規則為什麼要對得上。

SQLite 與 DuckDB 對識別字大小寫的處理

同一張 "Orders" 表搬到 SQLite 與 DuckDB，四種查法全部找得到那張表：

1CREATE TABLE "Orders" ("OrderId" INT);
2
3SELECT * FROM orders;     -- 不加引號、查小寫
4SELECT * FROM Orders;     -- 不加引號、照原樣
5SELECT * FROM "Orders";   -- 加引號、大小寫一致
6SELECT * FROM "orders";   -- 加引號、大小寫不一致
7-- SQLite、DuckDB：四句都找得到
8-- PostgreSQL：只有加引號、大小寫一致的那一句找得到，其餘三句都回 relation "orders" does not exist

這兩個引擎對識別字的大小寫不敏感，連引號都不會讓它變敏感。

這造成一個很難發現的可攜性問題：在 SQLite 上開發、程式碼裡大小寫混著寫，一路都正常；搬到 PostgreSQL 之後，凡是建表時加了引號而查詢時沒加的地方全部找不到表。錯誤出現的時機離寫下它的時機很遠。

保留字與各家的引號寫法

select、order、group 這些是語法的一部分，直接拿來當表名會在剖析階段（引擎把文字切成語法結構的那一步）就失敗：

1CREATE TABLE select (x INT);
2-- SQLite:    near "select": syntax error
3-- DuckDB:    Parser Error: syntax error at or near "select"
4-- PostgreSQL: syntax error at or near "select"

加上引號之後三家都接受，因為引號告訴剖析器這是一個名字而不是關鍵字。「要加引號」這件事各家一致，引號的寫法則不一致：

1CREATE TABLE "select" (x INT);
2-- SQLite、DuckDB、PostgreSQL：接受
3-- MySQL：ERROR 1064 語法錯誤，它預設把雙引號當成字串
4
5CREATE TABLE `select` (x INT);   -- MySQL 的識別字要用反引號
6
7SET SESSION sql_mode = CONCAT(@@sql_mode, ',ANSI_QUOTES');
8CREATE TABLE "order" (x INT);    -- 開了 ANSI_QUOTES 之後，MySQL 的雙引號才代表識別字

同一份 DDL 要跑在 MySQL 與另外幾家上，引號要逐家寫，或者乾脆不用保留字當名字。

保留字清單各家不完全相同，而且新版本會往清單裡加新的字——今天合法的名字在下個大版本可能變成保留字。這是「所有識別字一律加引號」這個慣例的主要理由。採用這個慣例的代價是每個名字都變長，而且從此大小寫必須逐字一致。

中文識別字在各家引擎上的處理

CREATE TABLE 顧客 (姓名 TEXT) 與 SELECT 姓名 FROM 顧客 在 SQLite、DuckDB 與 PostgreSQL 上都不用加引號就能跑。摺疊規則對中文沒有作用，因為那些字沒有大小寫。

引號的做法：全部不加、全部加與混用

全部不加引號、名字一律用小寫加底線。 這是 PostgreSQL 生態的主流，摺疊不會改變任何東西，換引擎也不受影響。代價是撞到保留字時仍然要加引號。

全部加引號。 名字逐字保存，保留字不成問題。代價是每個名字都要引號、大小寫從此一字不能錯，而且在不區分大小寫的引擎上，大小寫要逐字一致這個約束不會被驗證出來。

中間地帶——有些地方加、有些地方不加、名字又是大小寫混合的——在單一引擎上可能一直正常，換引擎時整批失效。選哪一種都行，混用不行。

大小寫這件事在 SQL 裡落在兩個彼此獨立的層。SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字 處理的是名字送進引擎會被怎麼摺疊，這一篇處理的是值被拿去比較時套的是哪一把尺。兩層的規則互不影響：PostgreSQL 把沒加引號的表名摺成小寫，卻不會把 'Anna' 這個值摺成小寫。

本篇把同一條規則作用的四個表面走完：什麼算相等、LIKE 為什麼會與等號分岔、誰排在前面、以及索引走不走得了。四者收在同一個處置上——規則要寫出來，而寫在資料庫、表或欄位哪一層決定它涵蓋到哪裡。

本篇的顧客表有五列：Anna、anna、ANNA、Ánna、佳穎。

等值比較在各家引擎的預設 collation 下命中的列

每一家的預設規則對大小寫與重音的規定不同，所以同一個等值條件在三家上命中的列不是同一批：

1WHERE 姓名 = 'anna'
2
3SQLite 3.51        anna
4PostgreSQL 18      anna
5MySQL 8.4          Anna, anna, ANNA, Ánna

MySQL 的預設 collation 是 utf8mb4_0900_ai_ci，名字裡的 ai 與 ci 就是它的規定：accent-insensitive 與 case-insensitive——重音與大小寫都不算差異，所以 Ánna 與 anna 在這條規則底下是同一個值。SQLite 與 PostgreSQL 的預設把這兩者都算差異，於是只有逐字相同的那一列命中。

這三個答案都正確，因為「相等」的定義本來就由那條規則給，而查詢的文字沒有選過它。一段在 MySQL 上寫好的登入查詢搬到 PostgreSQL，比對帳號的那一段會突然變成大小寫敏感，而它照樣執行、照樣回一批形狀正確的列。

SQLite 的 LIKE 與等號各自套用的比較規則

LIKE 是另一個做字串比較的運算子，而它套的規則未必與 = 相同：

1                    SQLite 3.51        PostgreSQL 18      MySQL 8.4
2= 'anna'            anna               anna               Anna, anna, ANNA, Ánna
3LIKE 'anna'         Anna, anna, ANNA   anna               Anna, anna, ANNA, Ánna

PostgreSQL 與 MySQL 的兩列一致，SQLite 的兩列分岔：它的 = 逐位元組比較，而它的 LIKE 預設不分大小寫。所以在 SQLite 上把 = 換成 LIKE（例如為了加一個 %）會順帶換掉比較規則，而這件事沒有任何提示。

SQLite 這個不分大小寫的範圍限定在 ASCII 字母：LIKE 'ánna' 在同一批資料上回零列，Ánna 沒有被當成同一個字串。所以那條規則的完整敘述是「A 到 Z 這二十六個字母摺疊，其餘逐位元組」，而不是「不分大小寫」。

要把它調成一致，PRAGMA case_sensitive_like = ON 讓 LIKE 跟著 = 走；反向的做法是在條件上寫 COLLATE NOCASE，讓 = 跟著 LIKE 走。選哪一邊都行，而選了要寫出來——沒寫出來的時候讀查詢的人得先知道它跑在哪一家引擎上，才知道這一句在比什麼。

collation 規定的排序先後

collation 除了規定兩個字串相不相等，也規定誰排在前面。同一批五個名字，三家排出三種順序：

1ORDER BY 姓名
2
3SQLite 3.51        ANNA, Anna, anna, Ánna, 佳穎
4PostgreSQL 18      anna, Anna, ANNA, Ánna, 佳穎
5MySQL 8.4          Anna, anna, ANNA, Ánna, 佳穎

SQLite 那一列是位元組的先後——大寫字母的碼位小於小寫，所以 ANNA 整批排在前面。PostgreSQL 這一列取決於資料庫建立時選的 collation，量測用的這個是 en_US.utf8（查法是 SELECT datcollate FROM pg_database），它照人類語言的習慣把大小寫視為同一個字母的變體、再用大小寫決定同分時的先後。同一段排序在 PostgreSQL 上改用 C 這條逐位元組比較的規則，順序就與 SQLite 一致：

1-- PostgreSQL 18，資料庫的 collation 是 en_US.utf8
2SELECT 姓名 FROM 顧客 ORDER BY 姓名;
3-- anna, Anna, ANNA, Ánna, 佳穎
4SELECT 姓名 FROM 顧客 ORDER BY 姓名 COLLATE "C";
5-- ANNA, Anna, anna, Ánna, 佳穎（與 SQLite 的預設順序相同）

同一家引擎、同一批資料，換一條規則就換一種順序，而 SQLite 的預設順序就是位元組序這件事也因此驗得出來。

MySQL 那一列要換個方式讀。在 ai_ci 底下四個 A 開頭的名字彼此相等，所以它們之間沒有先後可言——那一列印的是它們進表的順序。同一個排序鍵改由 GROUP_CONCAT 取回，四個名字的順序整個倒過來：

1-- MySQL 8.4，同一張表、同一批資料
2SELECT 姓名 FROM 顧客 ORDER BY 姓名;
3-- Anna, anna, ANNA, Ánna, 佳穎（進表的順序）
4SELECT GROUP_CONCAT(姓名 ORDER BY 姓名) FROM 顧客;
5-- Ánna,ANNA,anna,Anna,佳穎（四個 A 開頭的名字倒過來，佳穎仍在最後）

兩次都沒有違反 collation，因為 collation 對這四個之間什麼都沒有規定。這是 collation 與分頁交會的地方：一條把大小寫與重音都忽略的規則，會讓原本以為唯一的排序鍵變成不唯一，而沒有規定的那一段在分頁時會變成同一列出現兩次、另一列一次都不出現——SQL.12 分頁的排序鍵與接續標記 寫那個機制與把排序鍵補到兩兩可分的判斷標準。

索引的比較規則與條件的比較規則

索引把值按某一條規則排好，所以它只服務照同一條規則發問的條件。索引與條件的規則對不上，在小表上感覺不出來——資料長到某個量之後前綴搜尋開始變慢，而查詢與索引都沒有動過。這一節的計畫也要在夠大的表上才看得出來——五列的表無論條件寫成什麼，引擎都直接掃完，所以下面兩組輸出量在二十萬列的同結構表上。SQLite 上的三種問法，索引是同一個：

1CREATE INDEX ixn ON 顧客(姓名);            -- 預設規則，逐位元組
2
3WHERE 姓名 = 'anna'          SEARCH ... (姓名=?)      查找
4WHERE lower(姓名) = 'anna'   SCAN                     整段掃過
5WHERE 姓名 LIKE 'ann%'       SCAN                     整段掃過

第二行是欄位被函式包住，索引上排好的是原值而條件問的是摺過的值，兩者對不起來（Sargable）。第三行的成因不同：前綴比對本來可以翻成索引上的一段範圍，而 LIKE 預設不分大小寫，索引卻是逐位元組排的——規則對不上，範圍就算不出來。條件的規則與索引的規則，換掉任何一個都讓計畫回到範圍查找，而兩種換法回的列不同——改條件的規則也改掉了 LIKE 的答案：

 1-- 改條件的規則：LIKE 改成分大小寫，回到位元組規則
 2PRAGMA case_sensitive_like = ON;
 3EXPLAIN QUERY PLAN SELECT * FROM 顧客 WHERE 姓名 LIKE 'ann%';
 4-- SEARCH ... (姓名>? AND 姓名<?)
 5-- 本篇五列的顧客表上回 anna
 6
 7-- 改索引的規則：LIKE 維持預設的不分大小寫，另建一個按摺疊規則排的索引；SQLite 的索引一定要取名字
 8PRAGMA case_sensitive_like = OFF;
 9CREATE INDEX ixn_nocase ON 顧客(姓名 COLLATE NOCASE);
10EXPLAIN QUERY PLAN SELECT * FROM 顧客 WHERE 姓名 LIKE 'ann%';
11-- SEARCH ... (姓名>? AND 姓名<?)
12-- 本篇五列的顧客表上回 Anna, anna, ANNA

PostgreSQL 上，索引與條件套的規則對不上，同樣會讓前綴搜尋用不到索引，只是外觀不同：

1WHERE 姓名 = 'anna'          Index Cond: (姓名 = 'anna')          查找
2WHERE lower(姓名) = 'anna'   Filter: (lower(姓名) = 'anna')       逐列過濾
3WHERE 姓名 LIKE 'ann%'       Filter: (姓名 ~~ 'ann%')             逐列過濾

en_US.utf8 的排序規則與位元組序不同，所以 ann 這個前綴在索引上不對應一段連續的區間。PostgreSQL 的解法是另建一個按位元組排的索引；lower(姓名) 那一行則由建在運算式上的索引接住：

1-- 前綴搜尋：text_pattern_ops 讓這個索引逐字元比較，不照資料庫的 en_US.utf8
2CREATE INDEX ON 顧客(姓名 text_pattern_ops);
3EXPLAIN SELECT * FROM 顧客 WHERE 姓名 LIKE 'ann%';
4-- Index Cond: (姓名 ~>=~ 'ann' AND 姓名 ~<~ 'ano')：前綴翻成一段範圍
5
6-- 欄位被函式包住：索引直接建在 lower(姓名) 上
7CREATE INDEX ON 顧客(lower(姓名));
8EXPLAIN SELECT * FROM 顧客 WHERE lower(姓名) = 'anna';
9-- Index Cond: (lower(姓名) = 'anna')

三種修法的共同形狀是讓索引與條件套同一條規則，而它們把改動放在不同的一邊：改條件、改索引的 collation、或另建一個按別的規則排的索引。比較規則對得上只是索引派得上用場的條件之一：條件的形狀是另一個（lower(姓名) 那一行就是形狀出的問題），而形狀與規則都對了之後，引擎還要看這個條件留下多少列才決定值不值得走索引，留下多少列怎麼估計在 Cardinality 與 Selectivity。

collation 宣告在資料庫、表、欄位或條件上各自的涵蓋範圍

預設值在單一環境底下是隱形的——查詢跑得對，沒有人會去問「相等」現在是怎麼定義的。它在三個時刻現形：換一家引擎、換一個資料庫（同一家引擎的不同資料庫可以有不同的 collation）、以及有人在一欄上單獨指定了規則而其餘欄位沒有。要同時支援好幾家引擎的時候，collation 只是要逐項盤點的預設差異之一，識別字的摺疊是另一項，換引擎才浮現的形態在 SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字 的「SQLite 與 DuckDB 對識別字大小寫的處理」一節；各家預設差異的完整並置與分級在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。

所以規則的住址要選定，而可選的住址比多數人用到的多。開頭那一句說 collation 掛在資料庫、表或欄位上——那是三層，越外層涵蓋越廣而越容易被裡層蓋掉：建庫時選的那一條是所有沒有另外指定的欄位的預設，建表時選的蓋過它，欄位上寫的又蓋過表。來歷不明的建表模板最常把規則留在表層或庫層，所以查一欄的實際規則要從欄位往外找，找到第一個明寫的為止。

寫在欄位上是最貼近資料的一種：姓名 VARCHAR(50) COLLATE utf8mb4_0900_as_cs（as_cs 是 accent-sensitive、case-sensitive）把這一欄固定住，往後每一段查詢、每一個索引都套它。寫在條件上（WHERE 姓名 = 'anna' COLLATE NOCASE）只涵蓋那一句。還有一個住址不在 collation 這條路上：寫入的時候就把值正規化，另存一欄摺過的版本，讀的時候比那一欄。開頭提過的登入查詢——帳號比對在 MySQL 上不分大小寫、搬到 PostgreSQL 突然變成分大小寫——實際的解法多半是這一種：比較規則變成一次寫入時的決定，而讀的那一句與它的索引都回到最單純的等值比較。同一個登入功能裡兩種住址各有位置：帳號欄整欄要不分大小寫，那是欄位的事；而某支後台工具要逐字比對，那是那一句的事。代價是寫在條件上的那一句走不了按預設規則建的索引。

判斷標準與約束那一條同源：一個保證要涵蓋往後的每一次使用，它就得寫在結構上，而不是靠每一句查詢各自記得。差別在於約束擋的是寫入，collation 決定的是讀出來的時候什麼算相等。

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

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

接不接受這段文字。 引擎檢查名字解析得到、型別配得上、子句的組合合乎規則。標準定死的那些各家一致；標準禁止而各家自行放寬的那些不一致，於是同一段查詢在一家報錯、在另一家跑得動（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（統計資訊）。

查詢的文字之外還有幾方在決定結果：識別字規則決定名字指向誰、collation 決定字串怎麼比、權限決定誰能送出這段 SQL、約束決定資料能長成什麼樣、最佳化器決定要花多久。寬鬆度與那五方的關係不同——它決定的是那五方各自收與不收的界線畫在哪裡，所以同一家引擎的寬鬆度會同時出現在名字、比較、分組等好幾個位置上，本篇把那些位置並置起來比較。

本篇先整理形態學——各家的分割長什麼樣、差異在什麼位置發聲；再談決策——哪幾種差異要在寫的當下就處理掉、什麼時候要重算。形態學是決策的輸入：不知道一個差異會在什麼時候發聲，就算不出提前處理它要付多少。

本篇的量測跑在四家引擎上：SQLite 3.51、DuckDB v0.10.3、PostgreSQL 18、MySQL 8.4。兩張表各兩列，下表的每一個寫法是這個區塊裡的一段查詢：

 1CREATE TABLE 顧客 (顧客編號 INT, 姓名 VARCHAR(20));
 2CREATE TABLE 訂單 (訂單編號 INT, 顧客編號 INT, 金額 INT);
 3INSERT INTO 顧客 VALUES (1, 'Anna'), (2, 'anna');
 4INSERT INTO 訂單 VALUES (101, 1, 700), (102, 1, NULL);
 5
 6-- 未分組欄位：訂單編號不在 GROUP BY 裡，也沒有被聚合
 7SELECT 顧客編號, 訂單編號 FROM 訂單 GROUP BY 顧客編號;
 8-- SQLite：1 101（這一組有兩列，它挑了其中一列）
 9-- DuckDB、PostgreSQL、MySQL：拒絕
10-- MySQL 在同一條連線先 SET SESSION sql_mode = '' 之後：1 101
11
12-- WHERE 用別名：兩倍在 SELECT 那一步才算出來
13SELECT 金額 * 2 AS 兩倍 FROM 訂單 WHERE 兩倍 > 0;
14-- SQLite、DuckDB：1400
15-- PostgreSQL、MySQL：拒絕
16
17-- 同表未取別名
18SELECT count(*) FROM 訂單, 訂單;
19-- SQLite：4；引用欄位時才拒，SELECT 訂單編號 FROM 訂單, 訂單 回 ambiguous column name
20-- DuckDB、PostgreSQL、MySQL：FROM 就拒絕，連 count(*) 都不收
21
22-- 字串比對
23SELECT 姓名 FROM 顧客 WHERE 姓名 = 'anna';
24-- SQLite、DuckDB、PostgreSQL：anna
25-- MySQL：Anna、anna（預設 collation 不分大小寫）
26
27-- 空值排序
28SELECT 訂單編號 FROM 訂單 ORDER BY 金額;
29-- SQLite、MySQL：102、101（空的排最前）
30-- DuckDB、PostgreSQL：101、102（空的排最後）

同一組寫法在各家引擎上收與不收的分割

下面這組寫法擺在 SQLite、DuckDB、PostgreSQL、MySQL 這四家引擎上，每一個寫法把這四家切成兩邊，而切法彼此對不上：

沒有一個寫法的分割能預測下一個寫法的分割。 未分組欄位只有 SQLite 收；WHERE 用別名換成 SQLite 與 DuckDB 一組；字串比對只有 MySQL 給另一個答案；空值排序又切成 SQLite 加 MySQL 對上 DuckDB 與 PostgreSQL。同表未取別名的分割與未分組欄位相同（都是 SQLite 對上其餘三家），這一點不減損上面那句——同一組引擎可以在兩個寫法上一起站在同一邊，而那不預測第三個寫法。

同一家引擎也可以坐在同一個寫法的兩邊。 未分組欄位在 MySQL 上是拒絕，而把 sql_mode 清空之後同一段查詢回 1 101——寬鬆度是「哪一家加上哪一組設定」，不是「哪一家」。SQLite 收下同一段查詢的時候也在補一個決定，只是補得更隱蔽：一組裡有幾列，它就挑其中一列的值交出來，而挑哪一列由執行方式決定、查詢的文字裡沒有說。收下與拒絕之間還有第三種可能——收下並替寫查詢的人選一個答案（多列一組的實例在 SQL.9 分組鍵的選擇：鍵與一組所代表的對象）。

寬鬆度的排名確實存在，而它只回答「收不收」這一個問題。 就收不收而言 SQLite 確實比 PostgreSQL 寬鬆——未分組欄位、WHERE 用別名、同表未取別名都是，字串比對上兩家一樣。問題在於字串比對與空值排序問的不是收不收：這兩個寫法四家全部收下，而答案不同。所以帶著「SQLite 最寬鬆、PostgreSQL 最嚴」去搬家，會準確地預期到「本來能跑的變成報錯」，而錯過完全沒有報錯的字串比對與空值排序。

各個寫法的完整推導住在它們自己的篇裡：未分組欄位在 SQL.2 子句的求值順序：每一步可用的欄位、語意模型擋下的寫法與各家引擎放寬的寫法 與 SQL.9 分組鍵的選擇：鍵與一組所代表的對象（SQLite 收下之後自己從那一組挑一列的值），WHERE 用別名在 SQL.11 查詢結果的列序：沒有 ORDER BY 時的來源與 ORDER BY 的規定範圍（WHERE 那一步發生在算出別名之前），同表未取別名在 SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接（同一張表出現兩次為什麼非取名不可），字串比對在 SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性（「相等」由哪一條比較規則定義），空值排序在 SQL.11 查詢結果的列序：沒有 ORDER BY 時的來源與 ORDER BY 的規定範圍（空值與任何值都比不出大小，落在哪一端由引擎規定）。表上沒有列出的一個實例形態特別隱蔽：識別字的大小寫。SQLite 與 DuckDB 連引號都不讓名字變敏感，所以在它們上面開發時混用引號的地方一路正常，搬到 PostgreSQL 才整批找不到表——SQL.14 識別字的規則：各家的大小寫摺疊、引號與保留字 寫各家的摺疊規則，以及兩種一致做法之間的中間地帶。

跨引擎差異的分級：當場報錯、等資料才報錯、靜默而輸出不同、靜默且輸出相同

上面那組寫法落在不同的級別上，而分級的依據是這個差異在正常的執行路徑上會不會發出聲音、在哪裡發。比較的單位是組態——不是「這一家與那一家」，是這一家的這個版本配上這一組設定，與另一家的另一個版本配上另一組設定。同一家跨一個大版本、或同一個資料庫換一條連線設定，都會產生下面每一種級別的差異。

當場報錯：剖析或名稱解析就出聲。 未分組欄位與 WHERE 用別名從寬鬆的那一家搬到嚴格的那一家時屬於這一級——第一次跑就報錯，訊息指名了那個欄位。當場報錯的差異最省事：它自己會現身，而且現身得早。

等資料才報錯：執行到某一筆資料才出聲。 約束的差異多半落在這一級——搬過去之後查詢照跑，直到第一筆違反它的資料寫進來。所以等資料才報錯的差異，現身時機由資料決定，而測試資料多半不含觸發它的那一筆。

靜默而輸出不同：不出聲，而輸出有差。 字串比對與空值排序在這一級。四家沒有一家報錯，回來的都是形狀正確的列，而列不一樣。要發現它得把同一段查詢在兩家上各跑一次、比對輸出。而這個比對不會有人自發去做，因為兩邊都沒有報錯——沒有任何東西提示這裡需要被比對。

靜默且輸出相同：不出聲，輸出也沒差。 SQL.18 外鍵與參照完整性：宣告、生效與查詢得到的保證 記的那幾種屬於這一級：同一段 REFERENCES 在一家建得出約束、在另一家被靜默丟掉，而建表語句成功、查詢也成功。靜默而輸出不同的差異至少在輸出上留下痕跡，靜默且輸出相同的差異連痕跡都不在輸出裡——它在系統目錄裡，要主動去查才看得到。

級別量的是發聲的位置，不是嚴重性、也不是偵測要花多少工夫。 修起來多麻煩與級別無關（當場報錯的差異可能要重寫整批查詢，靜默且輸出相同的差異可能只要加一行設定）；連偵測成本都不跟著級別排序——靜默且輸出相同的差異查一次系統目錄就有答案，而靜默而輸出不同的差異要持續做跨引擎的輸出比對，成本反而更高。分級真正決定的是什麼時候會知道有這件事：當場報錯的差異不必準備，它自己會現身；靜默且輸出相同的差異在往後任何一個時刻都不會自己浮現，所以知道它存在的唯一途徑落在搬家之前那一次盤點裡。盤點之外，搬家本身的流程——分階段、雙寫、切換——在 大規模 DB 遷移實戰。

可攜性的操作對象：引擎代為決定的位置與把決定寫出來的宣告

一段 SQL 單獨拿出來問「它可不可攜」是答不出來的。上面字串比對那個寫法在四家上有兩種答案，而把比較規則寫進欄位宣告之後，四家的答案就統一了（SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性 的〈collation 宣告在資料庫、表、欄位或條件上各自的涵蓋範圍〉一節）；統一到分大小寫或不分大小寫都做得到，兩個方向在四家上都量過。統一的是答案，宣告的文字本身仍然要逐家寫。下面是 顧客 表 姓名 那一欄的宣告，放進各家的 CREATE TABLE 裡：

 1-- 分大小寫：WHERE 姓名 = 'anna' 在四家都回 1 列
 2姓名 TEXT COLLATE BINARY                      -- SQLite
 3姓名 TEXT COLLATE C                           -- DuckDB；寫 COLLATE BINARY 是語法錯誤
 4姓名 TEXT COLLATE "C"                         -- PostgreSQL
 5姓名 VARCHAR(20) COLLATE utf8mb4_0900_as_cs   -- MySQL
 6
 7-- 不分大小寫：同一句在四家都回 2 列
 8姓名 TEXT COLLATE NOCASE                      -- SQLite
 9姓名 TEXT COLLATE NOCASE                      -- DuckDB
10姓名 TEXT COLLATE ci                          -- PostgreSQL，ci 要先建成一條非確定性的規則：
11    -- CREATE COLLATION ci (provider = icu, locale = 'und-u-ks-level2', deterministic = false);
12姓名 VARCHAR(20) COLLATE utf8mb4_0900_ai_ci   -- MySQL

空值排序那個寫法的決定是空值排在哪一端，把它寫進查詢就收回了引擎自己補的那一項：

1SELECT 訂單編號 FROM 訂單 ORDER BY (金額 IS NULL), 金額;
2-- 四家都回 101、102：金額 IS NULL 對空的那一列是真，真排在假後面
3SELECT 訂單編號 FROM 訂單 ORDER BY 金額 NULLS LAST;
4-- SQLite、DuckDB、PostgreSQL：101、102
5-- MySQL 8.4：ERROR 1064 語法錯誤

所以可攜性的操作對象多半是那些原本讓引擎代為決定的位置，而不是查詢本身。判斷標準是一句話：這段文字裡有沒有一個決定是它沒說、而由收下它的那一方補上的。 有，那個位置就是可攜性的斷點，不論它現在跑得多正常。這個判斷標準只涵蓋「有人補上的決定」；另一層是沒有任何一家引擎會代為決定的——查詢問對了沒有。那一層與寬鬆度無關，任何一家引擎的設定都管不到它，SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 寫它的判斷標準為什麼只能來自查詢之外。

「有沒有一個決定由收下它的那一方補上」這個判斷標準也解釋了為什麼可攜性在單一一組設定上測不出來——同一段查詢跑一萬次，那個被補上的決定每一次都一樣。「單一引擎」還不夠：同一個 MySQL 實例上，一條連線 SET SESSION sql_mode = ''、另一條用預設，同一段帶未分組欄位的查詢一邊回結果、一邊回 ERROR 1055。可攜性是查詢與那一組組態之間的性質，不是查詢的性質。

寫的當下要處理哪幾級差異：按目標組態數分的做法

「一律照最嚴格的標準寫」這條路有價錢：每一個原本可以讓引擎決定的位置都要自己寫出來，查詢變長，寫的人要知道每一條預設是什麼。這筆錢值不值得花，主要落在一個可以現在就數出來的量上——這段 SQL 現在跑在幾種組態上。「組態」指一家引擎的某個版本配上一組設定：換一家算一種，同一家換一個大版本或換一組連線設定也算一種，所以升級一次 MySQL 與換去 PostgreSQL 在組態數上是同一類事。

數出來是一的時候，還要問第二句：這個一會不會被別人改成二。數出來已經大於一的時候這一句不必問，答案在成本上沒有分別。「會不會被別人改成二」這個變數比「現在跑在幾種組態上」難察覺，因為它不在系統裡：資料庫由自己選的系統，與資料庫由客戶指定的系統，現在可能都只跑在一種組態上，而它們對同一段 SQL 的要求完全不同——資料庫由自己選的系統可以把整筆帳推遲，資料庫由客戶指定的系統推遲不了。

現在只有一種，而換不換由自己決定的時候，寬鬆度是引擎給的便利。代價全部推遲到換引擎的那一天，而那一天的工作量由靜默而輸出不同、靜默且輸出相同這兩級差異的數量決定——當場報錯的那些第一次執行就會出現。這條路的風險不在「會不會換引擎」，在換的時候有沒有辦法知道要查哪些位置：推遲的不只是工作，還有那份清單。

現在只有一種，而換不換由別人決定的時候（客戶指定的資料庫、或遲早要跟上的版本升級），那一天會來而日期不在自己手上，所以成本前置到寫的當下——但只前置靜默而輸出不同、靜默且輸出相同這兩級差異：把引擎自己補的決定寫出來（collation、空值的位置、識別字的引號）。當場報錯的差異留著不動，因為它搬家時會當場現身。這條路把「什麼時候知道」從搬家那一天提前到編譯那一刻，而付的是幾個子句的長度。

現在就不只一種的時候（產品裝在客戶各自的資料庫上、或測試與正式本來就不同家——測試與正式不同家是自己選的，裝在客戶的資料庫上不是，而在組態數大於一這個條件下兩者的成本相同），答案要完全一致，而完全一致無法只靠寫出那些決定——還要一份跨引擎的對照，同一批查詢在目標引擎上各跑一次、比對輸出。這一步的成本是持續的（每次改查詢都要重跑），換到的是靜默而輸出不同的差異不再靠人記得去查。而它有一個取得性的問題正好落在最需要它的那個情形上：產品裝在客戶的資料庫上時，客戶那一組版本加設定多半拿不到也不見得授權得起，這時退而求其次的是把自己手上那幾種組態的對照跑起來，並把「我們驗過哪幾種組態」寫成一份可以交出去的清單。跨引擎的對照無法由閱讀代替，理由與 SQL.20 關鍵字的宣告與引擎的行為那一層相同：宣稱的真值住在文字之外。

還有一條路不看組態數：用查詢建構器或物件關聯對映把 SQL 包起來。按組態數分的那三種做法是自己決定哪幾種差異要提前處理，這一條是把整個決定交出去——那一層自己要對每一家引擎做同樣的決定，而它做了哪些決定通常沒有寫在讀得到的地方。所以它換掉的是「誰來查這些引擎代為決定的位置」，不是「有沒有這些位置」。

按組態數做的選擇成立的前提：組態清單、引擎設定與測試環境

按組態數做的選擇綁在幾個前提上，前提換了就要重算。

目標組態的清單會變長。 維持一致的成本隨組態數量成長，而不是隨查詢數量成長，所以清單變長那一刻的重算幅度比想像中大。讓清單變長的事件多半來自外部——客戶要求裝在自己的資料庫上、併購進來一套用別家引擎的系統，或者一次跨大版本的升級。升級這一種特別容易被漏掉，因為它在直覺上不算「換引擎」，而上面那組寫法裡至少有一個（未分組欄位）收不收由 sql_mode 決定，這個變數的預設值跟著版本走，換了版本，收不收就可能跟著換。清單變長時，各家引擎對同一個寫法收不收的差異只是遷移要處理的其中一項：換引擎或把併購進來的系統搬過來，另外還有資料的搬運、雙寫與切換；每一步要留下什麼證明，Schema Migration Rollout 證據 用一次同庫內的欄位拆分示範證據長什麼樣。

引擎的設定會變。 未分組欄位在 MySQL 上收不收由 sql_mode 決定，而那個變數可以在連線層設定——同一個資料庫、同一段查詢，換一個連線設定就換一邊。這一類的差異不在查詢裡也不在 schema 裡，所以讀程式碼看不到它。

測試環境與正式環境要用同一家引擎。 測試跑 SQLite、正式跑 PostgreSQL 是最常見的一種不同家的配對，而靜默而輸出不同、靜默且輸出相同這兩級差異在這種配對下會延到正式環境才第一次浮現——那時它們看起來像資料問題。

跨引擎的一致之外：文字與引擎行為的一致

本篇談的一致是跨引擎的：同一段文字送進另一組組態會做什麼。同一段文字還有另一個讀者——下一個讀它的人，他會照著文字說的去理解資料，而文字說的與引擎做的可以不一樣。文字與引擎的一致在 SQL.20 關鍵字的宣告與引擎的行為：宣告落空的形態與查證，它處理文字說的與引擎做的分岔時，下一個讀者會被帶到哪裡。