Buffer Pool

為什麼需要 Buffer Pool

資料庫不可能每次存取都讀磁碟。Buffer pool（又稱 buffer cache、buffer manager）是記憶體中一塊由資料庫 自己管理的頁面快取，位於執行引擎與磁碟之間：

作業系統本來就有 page cache，為什麼資料庫還要自己做一份？因為資料庫比作業系統更了解自己的存取模式，而且有 OS 無法提供的正確性需求：

• 寫回順序必須受控：WAL 規則要求「日誌先落盤，資料頁才能落盤」（第 8 章）。OS page cache 會在任意時間把髒頁寫出， 資料庫無法阻止；而 的頁面被核心寫出時，資料庫甚至不知道。

• 置換策略需要語意：資料庫知道「這是一次性的全表掃描，別把熱頁面趕走」、「這是 B+Tree 根頁，永遠留著」；OS 只看到匿名的 4 KB 區塊。

• 預讀需要知識：資料庫知道 B+Tree 葉頁鏈結的下一頁是哪一頁、bitmap scan 接下來要讀哪些 heap 頁；OS 的 read-ahead 只能猜「下一個連續區塊」。

• 錯誤處理與可觀測性： 的 I/O 錯誤以 出現，無法乾淨地回報給交易；pin 計數、命中率等統計也只有自管快取才做得到。

Buffer Pool 的結構

• Frame：固定大小的記憶體槽，一次放一頁。PostgreSQL 的 就是一個 frame 陣列。

• Page table：從 page id 對應到 frame id 的雜湊表。PostgreSQL 把它切成 128 個分區 （），各自上鎖以降低爭用。

• 每個 frame 的元資料（PostgreSQL 的 ）：頁面標籤（哪個關聯的哪一頁）、dirty 位元、 pin count（refcount）、usage count、I/O 進行中旗標、內容 latch。PostgreSQL 把 refcount(18 bits)、 usage count(4 bits)、旗標(12 bits) 塞進一個 64-bit 原子變數，以 CAS 操作避免加鎖。

核心操作

fetch_page(pid):
  if pid in page_table:                 # 命中（hit）
    frame = page_table[pid]; frame.pin++; replacer.record_access(frame)
    return frame
  frame = free_list.pop() or replacer.evict()   # 未命中：找空 frame 或淘汰 victim
  if frame is None: raise "no unpinned buffers available"
  if frame.dirty:
    wal.flush_up_to(frame.page.lsn)     # WAL 規則：先刷日誌，才能寫髒頁
    disk.write(frame.page_id, frame.data)
  page_table.remove(frame.page_id)
  disk.read(pid, frame.data)             # 真正的 I/O
  page_table[pid] = frame; frame.pin = 1; frame.dirty = False
  return frame

unpin_page(pid, is_dirty):  frame.pin--; frame.dirty |= is_dirty
flush_page(pid):            wal.flush_up_to(lsn); disk.write(...); frame.dirty = False
new_page():                 pid = disk.allocate(); 取一個 frame 清零並登記

置換策略

當沒有空 frame 時，必須選一個 victim 淘汰。理想策略（Bélády 的 OPT：淘汰最久以後才會用到的頁）需要預知未來，實務上以歷史近似：

Clock 演算法

循序掃描洪水與對策

一次全表掃描會把整張表的頁面依序讀進來，每頁只用一次。在純 LRU 下，這會把所有真正熱門的頁面（索引根頁、常用的小表） 全部趕出去——這就是 sequential flooding。對策：

• MRU：對已知的掃描改用「淘汰最近用的」。

• ring buffer（環形緩衝）：掃描只在一小塊私有的 frame 子集內循環重用。PostgreSQL 對大於 /4 的表的循序掃描使用 256 KB 的 ring（），/ 用 16 MB（），VACUUM 用 2 MB（可由 調整）。

• 優先級提示：LRU-K、2Q、ARC 天生把「只被碰過一次」的頁排在淘汰隊伍前端。

Dirty Page 的寫回

被修改的頁面標記為 dirty，不會立刻寫回磁碟（write-back 而非 write-through）——這是效能的關鍵： 一頁可能被連續修改幾百次，只需寫回一次。髒頁在三種時機落盤：

1. 被選為 victim 時（前景寫回，會拖慢查詢）。

2. 背景寫入器（PostgreSQL 的 、InnoDB 的 page cleaner）定期掃描並寫出即將被淘汰的髒頁，讓前景少做事。

3. Checkpoint：把某個時間點之前的所有髒頁全部寫出，以縮短當機復原時間（第 8、11 章）。PostgreSQL 的 checkpointer 會把寫入 分散在 （預設 0.9）的時間內，避免 I/O 尖峰。

預讀與非同步 I/O

• 循序預讀：循序掃描時提前發出後續頁面的讀取。PostgreSQL 18 之前主要靠 OS read-ahead； 18 起引入 read stream 介面與真正的非同步 I/O（）， 由資料庫自己決定「往前看幾頁」（依最近的命中/未命中歷史動態調整），並把相鄰頁面合併成最大 的單一 I/O。

• 索引驅動的預讀：bitmap heap scan 知道接下來要讀哪些 heap 頁， 控制同時發出的預讀數量—— 在 SSD 上可以設到 100 以上。

• AIO 的另一個收穫：避免 double buffering（同一頁同時佔據 OS page cache 與 shared_buffers）。 搭配 direct I/O 時資料由 DMA 直接進 buffer pool，CPU 不必複製。InnoDB 長期以 加大 buffer pool（常設為 RAM 的 70–80%）； PostgreSQL 傳統建議 約 RAM 的 25%、其餘留給 OS cache，並以 告訴最佳化器總快取量。

完整走一遍：SELECT * FROM users WHERE id = 123

1. 解析器把 SQL 轉成查詢樹；最佳化器看到主鍵等值條件，估算 index scan 成本遠低於 seq scan（第 6 章），產生 。

2. 執行器啟動計畫節點，呼叫 B-tree 存取方法搜尋鍵 123。

3. B-tree 從 metapage 取得 root 頁號，向 buffer pool 要該頁：page table 命中（root 永遠是熱頁），pin、取讀 latch、二分搜尋找到子頁號。

4. 內部頁同樣幾乎必定命中。

5. 葉頁可能未命中：buffer pool 以 clock sweep 選出 victim（若為 dirty 先刷 WAL 再寫回），然後 從 SSD 讀 8 KB（約 100 \(\mu\)s）。 在葉頁中找到鍵 123 的索引項，取得 TID，例如 (block 1592, slot 3)。

6. 執行器拿 TID 向 buffer pool 要 heap 頁 1592（）。這是直接定址，不需要再搜尋。

7. 從 slot 3 取得 tuple，檢查 / 與目前快照決定可見性（第 9 章）；若不可見且 指向新版本，就沿鏈追蹤。

8. 把需要的欄位解出（可能要去 TOAST 表），unpin 兩頁，回傳結果。

總計：最佳情況 0 次 I/O，典型情況 1–2 次隨機讀，加上幾次 page table 查找與 latch 操作。 全表掃描則是 次循序讀——這個對比就是第 6 章成本模型的核心。

動手觀察：pg_buffercache

SELECT c.relname, count(*) AS buffers, sum(CASE WHEN isdirty THEN 1 ELSE 0 END) AS dirty,
       round(100.0 * count(*) / (SELECT setting::int FROM pg_settings WHERE name='shared_buffers'), 2) AS pct
FROM   pg_buffercache b JOIN pg_class c ON b.relfilenode = pg_relation_filenode(c.oid)
GROUP  BY c.relname ORDER BY buffers DESC LIMIT 10;

SELECT usagecount, count(*) FROM pg_buffercache GROUP BY 1 ORDER BY 1;   -- clock-sweep 的計數分佈

-- 緩衝池命中率（整個資料庫）
SELECT blks_hit::float / NULLIF(blks_hit + blks_read, 0) AS hit_ratio FROM pg_stat_database WHERE datname = current_database();