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

在每一頁各查一次的前提底下，兩次查詢之間伺服器不持有任何狀態，能拿來對齊兩頁的只有排序本身。

而 ORDER BY 只規定排序鍵分得出高下的列之間的先後；排序鍵的值相同的列（下面叫同分的列）彼此誰在前面，它沒有規定。那個規定怎麼運作、空值為什麼比不出大小，在 SQL.11 查詢結果的列序：沒有 ORDER BY 時的來源與 ORDER BY 的規定範圍。整批取回的時候，同分的列先後不定無害；逐頁取回的時候，它變成同一筆資料出現兩次、另一筆一次都不出現。

本篇處理三件事：那個機制、把順序補到全序（任兩列都比得出先後）的判斷標準，以及位置式與值式兩種接續標記（cursor）各自成立什麼。對外要選哪一種分頁還牽涉到跳頁與總筆數要不要放棄、接續標記怎麼編碼、以及一致性承諾怎麼寫進契約，那些不在本篇裡：分頁之爭：offset 與 keyset 的定位機制、接續標記的表示法與不透明性條款 的〈選型的順序：跳頁與總數需求、定位機制、表示法〉一節給選型的三步（先問跳頁與總數、再選定位機制、最後定表示法）與各步的出口，〈不透明接續標記隱含的承諾與條款清單〉一節寫接續標記要對外承諾哪些條款，〈offset 與 keyset 定位機制的成本曲線與能力差〉一節另列出快照分頁與時間視窗這兩條本篇沒有的路；接續標記式的複雜度對照與 tiebreaker 設計在 Keyset Pagination。

本篇沿用 SQL.11 查詢結果的列序：沒有 ORDER BY 時的來源與 ORDER BY 的規定範圍 那一批訂單：在共用資料庫上把 101 的金額改成 700、再加 103 到 105 三張，讓五張訂單裡有三張同樣是 500 元。這三張同分的訂單正是分頁要處理的對象。

1UPDATE 訂單 SET 金額 = 700 WHERE 訂單編號 = 101;
2INSERT INTO 訂單 (訂單編號, 金額) VALUES (103, 500), (104, 300), (105, 500);
3-- 101 是 700 元；102、103、105 是 500 元；104 是 300 元
4-- 新加的三張沒有填顧客與下單日，本篇的查詢只用到訂單編號與金額

排序鍵不唯一時同分的列的先後

ORDER BY 金額 DESC 說的是金額大的在前。三張 500 元的訂單彼此之間沒有被規定，所以它們的先後與沒有 ORDER BY 時一樣，跟著計畫走：

1-- SQLite 3.51，逐頁取一列：第 n 頁是 OFFSET n-1
2SELECT 訂單編號 FROM 訂單 ORDER BY 金額 DESC LIMIT 1 OFFSET 0;
3-- OFFSET 1 到 OFFSET 4 各跑一次同一段查詢
4-- 沒有索引：五頁依序是 101  102  103  105  104
5
6CREATE INDEX ix ON 訂單 (金額);
7-- 建了索引之後，同樣五段查詢依序是 101  105  103  102  104

整批看的時候這個差別無害——五張訂單一張不多一張不少，只是中間三張換了位置。分頁把它變成錯誤，因為每一頁是一次獨立的查詢：兩次查詢之間換了計畫的話，前一頁的最後一列可能在下一頁再出現一次，而另一列一次都不出現。計畫不換也會發生：PostgreSQL 依 LIMIT 加 OFFSET 的大小選排序方法，第一頁走 top-N heapsort、後面的頁走 quicksort，兩種方法對同分列給出不同的先後——一次 PostgreSQL 18 上的實測，一千列、同分很多，在同一個交易裡逐頁取完只拿到 757 個不同的列。

另一種形態不必換計畫就會發生：一邊翻頁一邊有人寫入，排在前面的列多了或少了，後面每一列的位置就跟著移動。下面叫它翻頁途中的寫入造成的位移。

1-- ORDER BY 金額 DESC LIMIT 2
2第 1 頁（OFFSET 0）              101, 102
3   ← 這時插入 106，金額 900
4第 2 頁（OFFSET 2）              102, 103
5第 3 頁（OFFSET 4）              105, 104

102 出現在兩頁上。OFFSET 2 的意思是「跳過排好之後的前兩列」，而新插入的 106 排在最前面，把所有列往後推了一格。原本在第二個位置的 102 被推到第三個，於是它同時是第一頁的最後一列與第二頁的第一列。

翻完三頁之後讀者手上是 101、102、102、103、105、104——六列裡有一列重複，而金額最高的那一筆 106 一次都沒出現。兩種偏差都不帶任何訊號：每一頁單獨看都是正確的查詢結果。查詢照跑、結果形狀正確而答案錯了，這一類錯誤共同的性質在 SQL.13 查詢的合法性與答案的正確性：引擎檢查的範圍、答案錯掉的成因與查證方法 的〈答案錯掉的成因分類與引擎不報錯的原因〉。

把排序鍵補到全序，以及用排序鍵的值當接續標記

補一個值不重複的欄位當末位排序鍵，同分的那幾列就有了規定：

1-- ORDER BY 金額 DESC, 訂單編號   全表順序：101,102,103,105,104
2OFFSET 0 → 101,102     OFFSET 2 → 103,105     OFFSET 4 → 104

同一段查詢跑幾次都是這個結果，換計畫也是。判斷標準是排序鍵的組合在「排序用的那條比較規則下」兩兩可分，這個性質叫全序：任兩列都比得出先後——「值不重複」還不夠，有兩種形態會讓不重複的鍵仍然排不出先後。一種是空值：一欄掛著 UNIQUE 而三列都是 NULL，約束成立而 NULL 之間比不出高下，SQLite 3.51 上建了索引之後同一段查詢回的順序就翻轉。另一種是比較規則把不同的值判成相等：MySQL 預設的 collation 底下 Anna／anna／ANNA／Ánna 四個值 COUNT(DISTINCT BINARY 姓名) 是 4 而 COUNT(DISTINCT 姓名) 是 1。看起來唯一的字串鍵因此可能不唯一，那條比較規則住在哪一層、各家預設是什麼，在 SQL.15 字串比較與 collation：相等、排序、LIKE 與索引可用性。

把主鍵接在排序鍵最後面之所以省事，是因為它同時避開了空值與比較規則這兩種形態——主鍵約束保證它不重複也不是 NULL，而數值型別的比較規則不會把兩個不同的數判成相等。SQLite 在這裡是例外：只有宣告成 INTEGER PRIMARY KEY 的那一欄擋得住 NULL，寫成 INT PRIMARY KEY 的主鍵照樣收得下好幾個 NULL，要當決勝鍵就得另外宣告 NOT NULL。所以排序鍵分不分得出高下，多半在寫 CREATE TABLE 的那一刻就定了：那一欄有沒有唯一約束、決勝鍵有沒有現成的欄位可用。backend 1.16 Schema 設計決定的查詢代價 的「這個鍵唯不唯一」一節走那個決定，並示範補決勝鍵治得好同分的列造成的重複與遺漏、治不好翻頁途中的寫入造成的位移。

補上唯一鍵治好了同分的列先後不定，治不好翻頁途中的寫入造成的位移。OFFSET 數的是位置，而位置會被前面新增或刪除的列改變。要讓分頁不受排在接續標記前面的寫入影響，接續標記得從位置換成值——記下上一頁最後一列的排序鍵，下一頁從那個值之後接著取。（排在接續標記後面的新插入照樣會進到後面的頁上；要讓整趟翻頁看到同一個時點的資料是另一回事，那需要快照，分頁之爭 的「定位機制的成本曲線與能力差」一節寫它。）

1-- 上一頁最後一列是 (金額 500, 訂單編號 102)
2SELECT 訂單編號 FROM 訂單
3WHERE 金額 < 500 OR (金額 = 500 AND 訂單編號 > 102)
4ORDER BY 金額 DESC, 訂單編號 LIMIT 2;
5-- 103,105

這個條件描述的是「排在那一列後面」，而它由排序鍵自己構成，所以中間插進來的 900 元訂單不影響它——那一列排在接續標記前面，本來就不該出現在後面的頁上。

條件要跟著排序方向寫。 SQL 有一種列值比較的簡寫 WHERE (金額, 訂單編號) < (500, 102)，它只在所有排序鍵同方向時與上面那段等價。金額遞減而訂單編號遞增的時候，同一批資料上兩種寫法回不同的列：

1展開式  WHERE 金額 < 500 OR (金額 = 500 AND 訂單編號 > 102)   → 103,105
2列值式  WHERE (金額, 訂單編號) < (500, 102)                    → 104

列值式回的是另一頁，而它照樣執行、照樣回一批形狀正確的列。兩個排序鍵都寫成遞減的時候列值式才對得上：

1-- 兩個排序鍵都遞減，全表順序是 101,105,103,102,104
2-- 上一頁最後一列是 (金額 500, 訂單編號 105)
3SELECT 訂單編號 FROM 訂單
4WHERE (金額, 訂單編號) < (500, 105)
5ORDER BY 金額 DESC, 訂單編號 DESC LIMIT 2;
6-- 103,102，與同一個排序下 OFFSET 2 LIMIT 2 取到的那一頁相同

OFFSET 的代價與頁數的關係

OFFSET n 要引擎按順序產出前 n 列再把它們丟掉，所以翻得越後面做的功越多。貴的是「用序數指位置」這個介面形狀，不是「找到第九十萬零一列」這件事——下面那張表的最後一列就是同一個深度用值定位，耗時與第一頁相同。一百萬列的表、排序鍵上有覆蓋索引，每次取二十列：

1CREATE TABLE t (id INTEGER PRIMARY KEY, k INTEGER);
2CREATE INDEX ix_k ON t (k, id);   -- 排序鍵 k, id 整組都在索引裡，取 id 不必回表
3
4-- OFFSET 式：先走過並丟掉排在前面的 n 列
5SELECT id FROM t ORDER BY k, id LIMIT 20 OFFSET 900000;
6
7-- 接續標記式：括號裡填上一頁最後一列的 (k, id)；兩個排序鍵同方向，列值比較可以直接用
8SELECT id FROM t WHERE (k, id) > (:上一頁的k, :上一頁的id) ORDER BY k, id LIMIT 20;

1-- SQLite 3.51，五次的實測，單位秒
2OFFSET 0        0.001  0.000  0.001  0.000  0.001
3OFFSET 100000   0.002  0.002  0.002  0.003  0.001
4OFFSET 500000   0.007  0.005  0.005  0.005  0.005
5OFFSET 900000   0.009  0.010  0.012  0.009  0.008
6接續標記式（深度 900000） 0.000  0.000  0.000  0.000  0.001

絕對值在這個規模上都很小，要看的是形狀：OFFSET 那一欄隨深度線性成長，接續標記式那一列與深度無關——它直接在索引上找到起點。所以「第一頁很快，翻到後面越來越慢」這個症狀有一個不必量測就成立的解釋：OFFSET 要先走過並丟掉排在前面的每一列，頁數越深要丟的越多。而它與索引建得好不好無關——上面那張表就是在索引已經覆蓋排序鍵的前提下量的。

OFFSET 的成長是代價問題的一個實例，而代價的一般形狀由資料與索引決定、不由寫法決定。代價的一般形狀在 SQL.17 查詢的代價，而 OFFSET 這一條特別之處在於它的成長與索引建得好不好無關。