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

資料庫效能受 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 操作。因此，優化索引結構與選擇合適的主鍵，對於最大化緩衝池效率至關重要。