各個決定的內容、決錯之後的症狀與機制所在的篇章

決錯之後的症狀有一個共同點：查詢照跑而答案不對。 只有兩個決定決錯時會當場出聲：量代價決錯時查詢慢得看得出來；交付時換了引擎，有一類差異第一次執行就報錯。SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 把跨引擎的差異按發聲的位置分級，第一次執行就報錯的叫當場報錯，其餘的差異要麼等某一筆資料才報錯、要麼始終靜默。其餘的決定決錯時欄位正常、列數合理，沒有任何東西提示要去檢查。

最常被跳過的決定：追問需求、設定判斷標準與對邊界

追問需求與設定判斷標準。 這兩個決定發生在打開編輯器之前，所以不留下任何痕跡——跳過了的查詢跟沒跳過的長得一模一樣。而跳過追問需求的代價是整段查詢答錯題，跳過設定判斷標準的代價是後面每一次修改都不知道有沒有改好。

對邊界。 一句需求描述的是資料正常時的樣子，而正式資料裡會出現提出需求的人沒想到、所以沒說的情形。以「哪幾天氣溫比前一天高」為例：同一個測站同一天有兩筆紀錄（感測器重送、補登、換設備之後兩套系統各寫一筆）、觀測日存的是哪一個時區的日期、三個月後才補進來的舊資料讓昨天的答案今天變了、同一個測站代號在某一天之後指向另一個地點。對邊界這個決定，就是在查詢寫好之後把這些情形逐一列出來，並決定每一種出現時查詢該回什麼。

這份清單沒有地方可以查。需求裡沒有它，schema 也只記下有哪些欄位、各是什麼型別，不記下資料在現實中會怎麼偏離預期。列得出幾種，取決於看過多少這個領域的資料：看過感測器重送，才會想到同一天可能有兩筆；看過補登，才會想到歷史答案會變。所以這一步的能力靠經驗累積，每在正式資料上遇到一種新的情形，就把它加進這個領域的查詢的檢查清單。

跳過它的症狀最難察覺：查詢在大部分資料上都對，只在碰到那幾筆特殊資料時算錯，而且不報錯。那幾筆往往要到有人拿結果去對帳，才被發現。

決定的前提：建表時定下的表的形狀

從追問需求到交付，每一個決定都做在一組已經建好的表上，而表的形狀是建表時的決定造出來的：欄位允不允許為空、鍵唯不唯一、長欄位放哪一張表、常一起取的資料切在幾張表、字串的比較規則寫在哪一層、外鍵生不生效。選寫法、補前提的時候，鍵唯不唯一、欄位允不允許為空已經定了；量代價的時候，長欄位放哪一張表、常一起取的資料切在幾張表也已經定了。這些建表時的決定替往後每一段查詢定了價——手上要交的是一份 schema 設計而不是一段查詢時，問題落在追問需求之前。以鍵唯不唯一為例：「哪幾天氣溫比前一天高」用自連接、視窗函數與相關子查詢三種寫法，共同押的前提，是同一個測站同一天只有一筆；表上有 UNIQUE (測站, 觀測日) 時這個前提由資料庫保證，沒有的話每一段查詢都得自己處理重複，否則自連接會把一列配成多列。每一個決定各自替查詢定了什麼代價，實測在 backend 1.16 Schema 設計決定的查詢代價。

在「哪幾天氣溫比前一天高」這句需求上做完全部決定的示範

SQL.22 查詢設計的完整示範：把「哪幾天氣溫比前一天高」從需求做到上線 拿「哪幾天氣溫比前一天高」這句需求從頭做完這些決定：把「前一天」追問成日曆上的前一天還是資料上的前一筆；用自連接、視窗函數與相關子查詢各寫一次，找出三者共同押的前提（同一個測站同一天只有一筆）；看漏掉相隔天數與漏掉分區的兩個錯誤版本：漏掉相隔天數的多報，漏掉分區的錯在哪個方向要看同一天兩個測站誰排在前面；把自連接再分成日期差與等值兩種寫法，在同一組資料上量這兩種自連接、視窗函數與相關子查詢的時間，差到三個量級，其中一種加了索引反而變慢；最後列出重複紀錄、時區、補登與測站搬家這幾種需求沒說的情形。

這句需求離一段可以執行的查詢還隔著幾個決定，而那些決定的答案都不在資料庫裡，也不在 SQL 裡。

本篇的查詢跑在自己的表上，不用共用的範例資料庫——氣溫資料需要缺測與多測站才顯示得出要講的那幾件事。輸出都是實際跑出來的，引擎是 SQLite 3.51.0。

寫查詢之前的追問：結果的用途、「前一天」的定義、缺測與測站數

下面四個追問，答案要在寫下任何一段查詢之前拿到，因為每一個的答案都會換掉後面全部的東西：

這個結果要餵給哪一個決定。 是要在超過門檻時發告警、是月報上的一張圖、還是模型的一個特徵。答案決定它跑幾次——一次性的查詢、每天排程一次、還是每次有人開頁面就跑一次。而跑的次數決定代價預算，代價預算決定後面代價量測那張表要看哪一欄。

「前一天」是日曆上的前一天，還是資料上的前一筆。 這兩個是不同的問題，而資料完整的時候它們的答案相同——所以在開發用的乾淨資料上分不出來，要等到缺測發生。

缺一天的時候要什麼答案。 三種都合理：跳過（沒有前一天就不算）、視為斷點（明確標示這裡量不到）、或者補值（用前後內插）。三種對應三段不同的查詢。

一個測站還是幾百個。 一個的時候整批資料就是一條時間序列；幾百個的時候「前一天」必須限定在同一個測站之內，而漏掉這個限定不會報錯。

這些追問的答案不在資料庫裡，也不在 SQL 裡，要去問人。而不問的話，每一個追問都會有一個預設答案被偷偷選走：多數人預設這是一次性的查詢、不去想它以後要跑幾次，預設寫成「資料上的前一筆」、預設跳過缺測、預設只有一個測站。

可驗收的需求敘述與帶缺測的驗收資料

追問的答案決定了要寫的是哪一段查詢。本篇往下取這一組：要餵給每天一次的排程報表、「前一天」指日曆上的前一天、缺測的那一天不算、而且有很多個測站。

翻成一句話：

對每一個測站，找出所有「同測站、日期剛好早一天」的那筆觀測存在、而且氣溫比它高的那些觀測。

這句話可以驗收，因為給定一組資料就說得出正確答案是哪幾筆。造一組刻意帶缺測的資料：

 1-- 各節的表名重複，照順序跑要先清掉上一節的（SQLite 的 DROP 一次只收一張表）
 2DROP TABLE IF EXISTS 氣溫;
 3CREATE TABLE 氣溫 (
 4  紀錄編號 INTEGER PRIMARY KEY,
 5  測站     TEXT,
 6  觀測日   TEXT,
 7  攝氏     INT
 8);
 9
10-- 台北的 3/05 缺測（感測器當天離線），其餘每天一筆
11INSERT INTO 氣溫 (測站, 觀測日, 攝氏) VALUES
12 ('台北','2026-03-01',18),('台北','2026-03-02',22),('台北','2026-03-03',20),
13 ('台北','2026-03-04',15),                          ('台北','2026-03-06',25),
14 ('台北','2026-03-07',24),
15 ('高雄','2026-03-01',26),('高雄','2026-03-02',25),('高雄','2026-03-03',28),
16 ('高雄','2026-03-04',27),('高雄','2026-03-05',29),('高雄','2026-03-06',30),
17 ('高雄','2026-03-07',28);

照上面那句話逐筆判，正確答案是四筆：

1台北  2026-03-02    22 > 18
2高雄  2026-03-03    28 > 25
3高雄  2026-03-05    29 > 27
4高雄  2026-03-06    30 > 29

台北的 3/06（25 度）不算——它的前一天是 3/05，而那一天沒有觀測。這一筆是整組資料的判斷標準：任何一段回它的查詢，都答錯了上面那句話。

自連接、視窗函數與相關子查詢各自押的前提

自連接把同一張表當成兩次出現，一次扮演「今天」、一次扮演「昨天」（SQL.7 表的出現與別名：表名的指稱、別名的作用範圍與自連接）：

1SELECT 今.測站, 今.觀測日
2FROM 氣溫 今
3JOIN 氣溫 昨
4  ON 昨.測站 = 今.測站                                  -- 限定在同一個測站之內
5 AND 昨.觀測日 = date(今.觀測日, '-1 day')              -- 「前一天」是日曆上的前一天
6WHERE 今.攝氏 > 昨.攝氏
7ORDER BY 今.測站, 今.觀測日;

date(今.觀測日, '-1 day') 是 SQLite 的日期運算，把字串日期往前推一天。別名 今 與 昨 各自標示這一次出現扮演什麼角色——欄位一定要帶前綴，兩次出現共用同一個表名的時候不帶前綴會直接被擋下（ambiguous column name: 測站）。

視窗函數沿著排好的順序往前取一列（SQL.10 分組與視窗函數：各自的產出、選用的依據與 LAG、LEAD 的相鄰列）：

1SELECT 測站, 觀測日 FROM (
2  SELECT 測站, 觀測日, 攝氏,
3         LAG(攝氏)   OVER w AS 前溫,
4         julianday(觀測日) - julianday(LAG(觀測日) OVER w) AS 相隔
5  FROM 氣溫
6  WINDOW w AS (PARTITION BY 測站 ORDER BY 觀測日)
7)
8WHERE 攝氏 > 前溫 AND 相隔 = 1
9ORDER BY 測站, 觀測日;

WINDOW w AS (...) 把窗的定義取個名字，讓兩個 LAG 共用同一個窗；julianday() 把日期換成可以相減的數值，兩筆相差幾天由它算出來。相隔 = 1 這個條件是必要的——LAG 交出的是排序後的相鄰一列，而需求要的是日曆上的前一天，兩者只在資料連續時相同。

相關子查詢對每一列去問一次「我的前一天是幾度」（SQL.8 IN、EXISTS 與 JOIN：列數、可取用的欄位與 NULL 的處理）：

1SELECT 測站, 觀測日
2FROM 氣溫 今
3WHERE 攝氏 > (SELECT 攝氏 FROM 氣溫 昨
4              WHERE 昨.測站 = 今.測站
5                AND 昨.觀測日 = date(今.觀測日, '-1 day'))
6ORDER BY 測站, 觀測日;

前一天不存在的時候括號裡那一段回零列，純量子查詢因此給出 NULL，而拿任何數字跟 NULL 比大小的答案是未知，那一列被 WHERE 丟掉（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。台北 3/06 正是靠這個機制被排除的——排除它的是空值的比較落在真、假之外的「未知」上，而查詢裡沒有任何一個條件在擋它。

三段都回同一批四列：

1台北  2026-03-02
2高雄  2026-03-03
3高雄  2026-03-05
4高雄  2026-03-06

三者押的前提不同。自連接押「同一個日期在同一個測站上只有一筆」——有兩筆的時候一列會配到多列，結果多出來（SQL.6 連接之後的列數與空缺：列數膨脹、外連接補的 NULL 與三值邏輯）。視窗函數押「排序鍵在每個分區裡分得出唯一的次序」——並列的時候「前一列」是哪一列沒有定義（SQL.12 分頁的排序鍵與接續標記：同分的列、全序與 OFFSET 的代價）。相關子查詢押「括號裡那一段最多回一列」——而回多列的時候兩家引擎的反應相反：PostgreSQL 18.6 報 more than one row returned by a subquery used as an expression，SQLite 3.51.0 靜默取其中一列往下算。這一條落在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機 的引擎差異上。

三個前提說的是同一件事：(測站, 觀測日) 這一組唯不唯一。那是 schema 上的一條約束，而三段查詢沒有一段查得到它有沒有成立——外鍵與約束要去系統目錄查，設計側的完整推導在 backend 1.16 Schema 設計決定的查詢代價。

漏掉相隔天數與漏掉分區的錯誤版本

上面那個 相隔 = 1 與 PARTITION BY 測站，漏掉任何一個查詢都照跑。

漏掉相隔天數的版本：

1SELECT 測站, 觀測日 FROM (
2  SELECT 測站, 觀測日, 攝氏,
3         LAG(攝氏) OVER (PARTITION BY 測站 ORDER BY 觀測日) AS 前溫
4  FROM 氣溫
5) WHERE 攝氏 > 前溫;

1台北  2026-03-02
2台北  2026-03-06      ← 多出來的
3高雄  2026-03-03
4高雄  2026-03-05
5高雄  2026-03-06

五筆。台北 3/06 拿 3/04 當「前一天」比，25 大於 15，於是被選中——它跨過了缺測的那一天，而缺測在結果裡沒有留下任何痕跡。

漏掉分區的版本（距離條件還在）：

1SELECT 測站, 觀測日 FROM (
2  SELECT 測站, 觀測日, 攝氏,
3         LAG(攝氏)   OVER (ORDER BY 觀測日) AS 前溫,
4         julianday(觀測日) - julianday(LAG(觀測日) OVER (ORDER BY 觀測日)) AS 相隔
5  FROM 氣溫
6) WHERE 攝氏 > 前溫 AND 相隔 = 1;

1高雄  2026-03-05

一筆，少了三筆。沒有分區的時候，ORDER BY 觀測日 把兩個測站同一天的列排在相鄰的位置，而同一天台北與高雄誰排在前面，這個排序鍵沒有決定——這正是視窗函數押的前提「排序鍵分得出唯一的次序」被打破的情形。SQLite 在這份資料上把台北排在前面，於是高雄 3/05 以外的高雄各列，前一列都是台北同一天的觀測，相隔天數是零，被 相隔 = 1 擋掉；台北 3/02 起的各列，前一列都是高雄前一天的觀測，相隔天數是一，比的卻是高雄的氣溫，而這組資料裡高雄每一天都比台北暖，台北一列都選不上。剩下的高雄 3/05 是因為台北 3/05 缺測，它的前一列才落在高雄 3/04。

把同一天的先後寫死、兩種排法各跑一次，同一段查詢的錯法跟著換：

 1-- 漏掉分區的查詢，窗的排序鍵補上測站，把同一天兩個測站的先後寫死
 2SELECT 測站, 觀測日 FROM (
 3  SELECT 測站, 觀測日, 攝氏,
 4         LAG(攝氏)   OVER w AS 前溫,
 5         julianday(觀測日) - julianday(LAG(觀測日) OVER w) AS 相隔
 6  FROM 氣溫
 7  WINDOW w AS (ORDER BY 觀測日, 測站)          -- 同一天台北排在高雄前面
 8) WHERE 攝氏 > 前溫 AND 相隔 = 1
 9ORDER BY 測站, 觀測日;
10-- ORDER BY 觀測日, 測站：      高雄 3/05，一筆（與不寫死次序時 SQLite 回的相同）
11-- ORDER BY 觀測日, 測站 DESC： 高雄 3/02、3/03、3/04、3/05、3/06、3/07，六筆
12--   高雄 3/02、3/04、3/07 的前一列是台北前一天，比的是台北的氣溫：多報
13--   台北 3/02 的前一列是高雄同一天，相隔天數是零：少報

兩個錯版都不報錯、輸出的欄位也完全正常。 漏掉相隔天數的版本每次都多報台北 3/06；漏掉分區的版本錯在哪個方向，由引擎怎麼排同一天的兩列決定，在本篇的資料上 SQLite 給的是少報。少報尤其危險——多報的還有機會被人發現數字怪，少報的看起來只是「那幾天沒有升溫」。

分辨它們要靠寫查詢之前就定下的正確答案。漏掉相隔天數的版本回了台北 3/06，撞上寫成可驗收的那句話時定下的「台北 3/06 不該出現」這個判斷標準；漏掉分區的版本在兩種排法下都沒有回台北 3/06，要拿四筆的正確答案逐筆比對才看得出錯。那份正確答案要在寫查詢之前就決定好，寫完再回頭挑資料的人，會挑到讓自己通過的那一組。

代價：日期差自連接、等值自連接、視窗函數與相關子查詢的實測

三種寫法都答對了，而「哪個比較快」要向引擎問（SQL.17 查詢的代價：資料分布、索引與寫法各自的影響）。把資料放大到二十個測站、兩年、每隔九十七天缺一天，共 14460 列：

 1-- 各節的表名重複，照順序跑要先清掉上一節的（SQLite 的 DROP 一次只收一張表）
 2DROP TABLE IF EXISTS 氣溫;
 3CREATE TABLE 氣溫 (紀錄編號 INTEGER PRIMARY KEY, 測站 TEXT, 觀測日 TEXT, 攝氏 INT);
 4
 5-- d 產生 0 到 729 的天數位移，s 產生 1 到 20 的測站編號
 6-- (i+j) % 97 <> 0 這個條件讓每個測站隔一段時間缺一天
 7WITH RECURSIVE d(i) AS (SELECT 0 UNION ALL SELECT i+1 FROM d WHERE i < 729),
 8               s(j) AS (SELECT 1 UNION ALL SELECT j+1 FROM s WHERE j < 20)
 9INSERT INTO 氣溫 (測站, 觀測日, 攝氏)
10SELECT '站'||j, date('2024-01-01', i||' day'), 10 + (i*7+j*13) % 25
11FROM s, d WHERE (i+j) % 97 <> 0;

自連接分兩種寫法量。兩者的演算法相同，差別只在「前一天」那個條件寫成什麼形狀：

1-- 以下是同一段自連接的 ON 子句，兩種寫法只差這一行，其餘逐字相同。
2-- 這個區塊是片段，不能單獨執行——完整的自連接查詢在〈自連接、視窗函數與相關子查詢各自押的前提〉那一節。
3
4-- 日期差自連接：等號兩邊的欄位都包進函式，算日期差
5ON 昨.測站 = 今.測站 AND julianday(今.觀測日) - julianday(昨.觀測日) = 1
6
7-- 等值自連接：等值比較，函式只作用在「今」那一側，「昨」那一側是索引上找得到的值
8ON 昨.測站 = 今.測站 AND 昨.觀測日 = date(今.觀測日, '-1 day')

量的是兩種自連接加上視窗函數與相關子查詢這四段（count(*) 版本，不帶 ORDER BY——排序會另外加一筆成本，蓋過要比的東西）。「有索引」那一欄是建了這個索引之後再量一次：

1CREATE INDEX ix_站日 ON 氣溫(測站, 觀測日);
2
3-- 拿掉它再量「沒有索引」那一欄：
4-- DROP INDEX ix_站日;

計畫用 EXPLAIN QUERY PLAN 加在查詢前面取得，例如：

1EXPLAIN QUERY PLAN
2SELECT count(*) FROM 氣溫 今 JOIN 氣溫 昨
3  ON 昨.測站 = 今.測站 AND julianday(今.觀測日) - julianday(昨.觀測日) = 1
4WHERE 今.攝氏 > 昨.攝氏;

四種形態各跑三次取最小值。計時在行程內——不是 sqlite3 的 .timer，那個量的是整個 CLI 行程；這裡是在一支宿主程式裡繞迴圈（Python 的 sqlite3 模組加 time.perf_counter()），因為行程啟動是個大常數，會把十五倍壓成不到兩倍。表格之後另外對日期差自連接做了一輪七次的重複性量測，用來確認那個反直覺的結果不是離群值：

四段查詢的答案完全相同，而時間橫跨三個量級。其中四個現象要逐個看。

日期差自連接與等值自連接的差別只在條件的形狀，而它是七十倍。 同一個自連接、同一個演算法，把 julianday(今.觀測日) - julianday(昨.觀測日) = 1 換成 昨.觀測日 = date(今.觀測日, '-1 day') 就從 739 毫秒掉到 10 毫秒。原因是日期差自連接把「今」與「昨」的觀測日都包進函式裡，引擎沒有辦法拿索引上的值去比；等值自連接的函式只作用在「今」的觀測日上，引擎在「昨」裡要找的是一個算好的值（Sargable）。在幾十列的開發資料上，兩種形狀都是零毫秒，所以這個差別要到資料量上來之後才看得到。

日期差自連接加了索引之後變慢。 739 毫秒變成 1045 毫秒。這一條反直覺，所以單獨對它再跑一輪七次量測確認：兩段的範圍不重疊（735–780 對上 955–1252），不是離群值。計畫說明了原因：

1沒有索引    SCAN 今
2            SEARCH 昨 USING AUTOMATIC COVERING INDEX (測站=?)
3
4有索引      SCAN 今
5            SEARCH 昨 USING INDEX ix_站日 (測站=?)

沒有索引的時候 SQLite 當場替這段查詢建了一個覆蓋索引，內層要的欄位全部在索引裡。有了 ix_站日 之後它改用那一個，而那個索引只含 (測站, 觀測日)、不含 攝氏，於是每一列內層都要多回表一次取攝氏。手動建的那個索引比引擎當場建的差，所以加了之後變慢——這件事沒有辦法從查詢的文字推出來，只能問計畫。

相關子查詢從四段裡最慢的變成僅次於等值自連接。 沒有索引時 3971 毫秒，有索引時 8 毫秒，差了五百倍。兩份計畫的差別在子查詢底下那一行：

1沒有索引    SCAN 今
2            CORRELATED SCALAR SUBQUERY 1
3              SCAN 昨                                            ← 「今」的每一列都把「昨」整張掃一遍
4
5有索引      SCAN 今
6            CORRELATED SCALAR SUBQUERY 1
7              SEARCH 昨 USING INDEX ix_站日 (測站=? AND 觀測日=?)   ← 「今」的每一列在索引上查一次

子查詢逐列執行這個結構沒有變，變的是每一次的單價。所以「相關子查詢慢」這個說法要加一個條件：它慢在那個逐列查找沒有索引可用的時候。

視窗函數對索引幾乎無感（13 對 12 毫秒），而計畫上有變化（只列產生窗那一層）：

1沒有索引    SCAN 氣溫
2            USE TEMP B-TREE FOR ORDER BY       ← 先把整張表排成 PARTITION BY 測站 ORDER BY 觀測日 的順序
3
4有索引      SCAN 氣溫 USING INDEX ix_站日       ← 沿索引讀出來就是這個順序，排序那一行消失

索引本身就提供了窗要的順序，省下的排序成本在這個資料量上還看不出來。

回到「這個結果要餵給哪一個決定」那個追問。每天排程跑一次的報表，四種形態都可以接受，那就挑最好讀的；每次開頁面就跑一次的話，日期差自連接那一列的數字會直接變成使用者等待的時間。

需求沒說而資料會有的情形：同日重複、時區、補登與測站搬家

「對每一個測站，找出所有同測站、日期剛好早一天的那筆觀測存在、而且氣溫比它高的那些觀測」這句可驗收的話管住了缺測。下面這幾件需求同樣沒說，而資料遲早會有。

同一個測站、同一天有兩筆。 感測器重送、補登、或者換了設備之後兩套系統各寫一筆。這打破的是三種寫法共同押的那個前提——(測站, 觀測日) 唯一——而三種寫法被打破之後的反應各不相同：自連接的一列會配到多列，結果多出來；視窗函數的「前一列」在並列之間沒有定義，同一段查詢可以給出不同答案；相關子查詢在 PostgreSQL 上報錯、在 SQLite 上靜默取其中一列。三種寫法對同一件事的反應完全不同，而在本篇用的 SQLite 上沒有一種會出聲——會出聲的那一種要換到 PostgreSQL 才看得到。 要決定的是哪一筆算數（最後寫入的、還是某個來源優先），而這個決定屬於 schema——一條 UNIQUE (測站, 觀測日) 約束把它前移到寫入的那一刻。

時區。 觀測日 存的是哪個時區的日期。跨時區的測站各自用當地日期的話，「前一天」在資料上是對的而在比較上不可跨站；統一存 UTC 日期的話，當地的「一天」會被切開。這件事在單一時區的開發環境裡量不出來。

補登的資料改變歷史答案。 台北 3/05 的觀測三個月後補進來了，同一段查詢在同一段日期上回的列跟著變——而且是對的：

 1-- 台北 3/05 補登，當天 12 度
 2INSERT INTO 氣溫 (測站, 觀測日, 攝氏) VALUES ('台北','2026-03-05',12);
 3
 4-- 〈自連接、視窗函數與相關子查詢各自押的前提〉那一節的自連接，原樣再跑一次
 5SELECT 今.測站, 今.觀測日
 6FROM 氣溫 今
 7JOIN 氣溫 昨
 8  ON 昨.測站 = 今.測站
 9 AND 昨.觀測日 = date(今.觀測日, '-1 day')
10WHERE 今.攝氏 > 昨.攝氏
11ORDER BY 今.測站, 今.觀測日;
12-- 補登之前：四筆
13-- 補登 12 度之後：五筆，多出台北 2026-03-06（25 > 12），它現在有前一天了
14-- 補登的是 17 度的話：六筆，台北 2026-03-05（17 > 15）也被選中

報表若把結果存下來，存的那一份與重跑的那一份會不同。要決定的是這份報表回答的是「現在資料庫怎麼說」還是「當時我們知道什麼」，兩種要的儲存方式不同。

測站搬家。 同一個 測站 值在某一天之後指的是另一個地點。PARTITION BY 測站 會把搬家前後接成同一條序列，而那一天的「比前一天高」比的是兩個地方。這一類問題不在查詢裡，在識別碼的語意有沒有隨時間改變。

四件事有一個共同點：它們都讓查詢繼續回出形狀正確的列。沒有一件會讓程式停下來（SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法）。

上線之前的決定：答案變動的偵測、資料量成長與換引擎

追問、判斷標準、寫法、前提、代價與邊界都處理過之後，這段查詢會跑、答案對、代價也量過了。剩下的三件事有一個共同點：它們全部不在這段文字裡——資料會變、計畫會重選、方言會換，而查詢的字面對這三件事完全沉默。

答案變了要不要有人知道。 台北 3/05 補登那種情形會讓同一段日期的答案改變。要不要偵測，取決於「餵給哪一個決定」那個追問——告警要知道，月報的圖不必。

資料量長大之後排名會重排。 代價量測那張表是 14460 列上的結果。列數再大一個量級，日期差自連接與相關子查詢的數字會變，而等值自連接與視窗函數未必。判斷要重問一次計畫，而且要在改動索引之後再問一次——日期差自連接已經示範過加索引可以讓事情更糟。

換一家引擎，這四段都要改寫。 四段全部用了 SQLite 的日期函式——兩種自連接與相關子查詢用 date(x, '-1 day') 或 julianday()，視窗函數用 julianday()。同一個日期運算，PostgreSQL 要先把欄位轉成日期，寫成 CAST(觀測日 AS DATE) - 1（本篇的觀測日宣告成 TEXT，直接寫 觀測日 - INTERVAL '1 day' 會回 operator does not exist: text - interval）；MySQL 寫成 DATE_SUB(觀測日, INTERVAL 1 DAY)，文字欄會被隱含轉成日期；WINDOW w AS (...) 這個具名窗各家支援程度不同。這一層的差異第一次執行就會報錯，屬於當場報錯的那一級、最省事——而同一段查詢還有不報錯的差異，分級在 SQL.19 引擎寬鬆度與可攜性：各家對同一組寫法的差異、分級與處理時機。

各個決定在這一題上的做法對照

每個決定要決定什麼、決錯之後的症狀、背後的機制在哪一篇，都在 SQL.0 一段查詢從需求到上線的決定：追問需求、設定判斷標準、選寫法、補前提、量代價、對邊界與交付；下表只對照這一題在每個決定上做了什麼：

查詢之外的接點：schema 設計、計畫工具與查詢預算

交付之後，這一題就交出去了。而從需求到上線的這些決定裡，有三個各自連到查詢之外的一個領域。

選寫法與補前提的接點在設計那一側。三種寫法押的同一個前提是 (測站, 觀測日) 唯不唯一，而那不是查詢能決定的事——它是建表時的一個決定。同樣的決定還有五個（可空性、表有多寬、常一起取的資料切在幾張表、字串的比較規則寫在哪一層、外鍵生不生效），每一個都在替往後每一次查詢定價，逐條實測在 backend 1.16 Schema 設計決定的查詢代價。

量代價的接點在工具那一側。本篇讀的計畫只有三四行，真實系統的計畫有巢狀節點與估計列數，而且要分得出「估計錯了」與「真的很慢」。PostgreSQL Query Optimization 給 EXPLAIN / EXPLAIN ANALYZE / auto_explain 三層工具的分工，以及統計過時讓計畫選錯的實際案例。

追問需求的接點在預算那一側。追問需求時問的是這份結果餵給哪一個下游用途，而那個答案決定它跑幾次；一個請求裡跑幾段查詢則有另一套預算，兩者相乘才是真正的代價。backend 1.13 應用層查詢反模式與 Query 預算 處理一個請求裡跑幾段查詢的那一套預算。

換一個題目的話，這些決定照樣要做，而追問需求得到的答案與需求沒說的那些邊界會全部不同——那正是為什麼它們是追問而不是清單。