# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Ben Dicken (@BenjDicken) · 平台：X (Twitter) · 日期：2026-04-13

> 原始來源：https://x.com/benjdicken/status/2043324099200725012

## 中文摘要

資料庫效能受 B-tree 結構與主鍵選擇影響。

資料庫效能深受 B-tree 索引結構影響，其中資料表規模與主鍵的選擇直接決定了查詢與寫入的效率。本文探討了 B-tree 與 B+tree 的運作機制，並分析為何選擇合適的主鍵對系統效能至關重要，同時提醒開發者需定期審視索引狀態以避免效能瓶頸。

**資料表規模與效能關聯**
資料表的規模會透過 B-tree 的深度直接影響效能。以 8k 頁面大小與 16 位元 UUID 為例，B-tree 的深度與資料列數量的關係如下：
- 1 層：約 370 列
- 2 層：約 13.8 萬列
- 3 層：約 5,000 萬列
- 4 層：約 200 億列

資料表規模越大，查詢成本越高，這不僅適用於資料表本身（MySQL 叢集索引），也適用於索引。此外，資料表規模還會影響以下層面：
- 記憶使用：小型資料表可完全載入記憶，讀取速度快；大型資料表則需頻繁讀取磁碟並造成快取流失。
- 索引維護：索引數量越多，插入資料時的維護成本越高，對於 Postgres 而言，還會增加 Vacuum 的負擔。
建議開發者定期盤點資料表與索引，清理膨脹的資料、移除未使用的索引，並在必要時進行分區。

**B-tree 與 B+tree 的運作機制**
B-tree 是資料庫管理系統（DBMS）的核心結構，透過節點與子指標來組織資料。B+tree 則是其更進階的變體，被 MySQL 的 InnoDB 引擎廣泛採用，其主要差異在於：
- 鍵值對僅儲存在葉節點（Leaf nodes）。
- 非葉節點僅儲存鍵與對應的子指標。
- 節點間具備雙向連結，有利於順序遍歷。
B+tree 的優勢在於非葉節點不需儲存實際值，因此能容納更多鍵，使樹狀結構更淺，進而提升搜尋效率。

**主鍵選擇對效能的影響**
主鍵的選擇直接決定了資料在磁碟上的佈局，進而影響效能。開發者應謹慎選擇：
- 使用 UUIDv4（128 位元）：由於其隨機性，插入時的節點位置不可預測，導致頻繁的讀寫與頁面分裂，效能較差。
- 使用順序整數（如 BIGINT UNSIGNED AUTO_INCREMENT）：插入路徑固定在樹的最右側，資料在葉節點層級保持排序，且 BIGINT（8 位元組）比 UUID（16 位元組）更小，能讓每個節點容納更多鍵，使樹狀結構更淺，查詢更快。

**InnoDB 與緩衝池機制**
InnoDB 引擎以 16k 為預設頁面大小，並透過「緩衝池」（Buffer Pool）作為記憶快取，位於磁碟頁面與查詢執行之間。當 MySQL 執行查詢時，會優先檢查頁面是否已存在於緩衝池中，若有則直接讀取，避免磁碟 I/O 操作。因此，優化索引結構與選擇合適的主鍵，對於最大化緩衝池效率至關重要。

## 標籤

教學資源, 其他, Database