MySQL Memory 引擎淺析（一）：官方文檔深度譯解與特性全景圖

專案因快取需求評估 Memory 引擎，過程中發現官方文檔僅提供英文版，且網路中文資料多有過時或片面。本文系統譯解 MySQL 5.5 官方文檔 The MEMORY Storage Engine 章節，並補充架構對比、適用場景與避坑指南，作為技術選型參考。

Memory 引擎核心定位

MEMORY 存儲引擎將表的數據存放在內存中。MEMORY 替代以前的 HEAP 成為首選項，但同時向下兼容，HEAP 仍被支持。

• 資料 100% 駐留記憶體，重啟即消失（唯留 .frm 結構檔）。
• 預設使用 Hash 索引，等值查詢極快；可選 B-Tree 索引支援範圍查詢。
• 表級鎖，不支援交易、外鍵、行鎖、全文索引、GIS、BLOB/TEXT。

Memory vs MySQL Cluster (NDB) 深度對比

官方白皮書 Scaling Web Services with MySQL Cluster 指出：NDB 在功能超集上完勝 Memory，若新架構可考慮直接採用 NDB。

完整特性支援矩陣

建表語法與索引選擇

-- 基本建表
CREATE TABLE t (id INT, data VARCHAR(100)) ENGINE = MEMORY;

-- 指定 Hash 索引（預設）
CREATE TABLE lookup (id INT, INDEX USING HASH (id)) ENGINE = MEMORY;

-- 指定 B-Tree 索引（支援範圍查詢、ORDER BY）
CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;

索引選擇原則： 等值查詢（=, IN）→ Hash；範圍/排序（>, <, BETWEEN, ORDER BY）→ B-Tree。高重複度鍵值下 Hash 索引更新/刪除效能急劇下降，必須改用 B-Tree。

關鍵限制與行為細節

• 固定行長度： VARCHAR(255) 實際佔用 255 字元空間，CHAR 與 VARCHAR 無差異。
• 不支援 BLOB/TEXT： 嘗試建立將報錯。
• 最大索引 64 個/表，每索引 16 欄位，鍵長 ≤ 3072 位元組。
• 支援 AUTO_INCREMENT、INSERT DELAYED、NULL 欄位索引。
• 非臨時表跨連線共享，臨時表連線隔離。
• 刪除行不釋放記憶體： 需 ALTER TABLE ... ENGINE=MEMORY 重建或 TRUNCATE/DROP 才釋放。
• 啟動自動填充： --init-file 載入 INSERT ... SELECT 或 LOAD DATA。

記憶體用量計算與容量規劃

單行記憶體估算公式（官方文檔）：

SUM_OVER_ALL_BTREE_KEYS(max_length_of_key + sizeof(char*) * 4)
+ SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2)
+ ALIGN(length_of_row + 1, sizeof(char*))

• sizeof(char*)：32位系統 4 位元組，64位系統 8 位元組。
• ALIGN：向上對齊至指標大小倍數。

動態調整單表上限

-- 設定下一個 CREATE TABLE 的上限為 1MB
SET SESSION max_heap_table_size = 1024*1024;
CREATE TABLE t1 (id INT PRIMARY KEY) ENGINE = MEMORY;

-- 設定下一個為 2MB
SET SESSION max_heap_table_size = 1024*1024*2;
CREATE TABLE t2 (id INT PRIMARY KEY) ENGINE = MEMORY;

注意： max_heap_table_size 優先級高於 MAX_ROWS。重啟後所有表恢復全域設定值。

複寫環境特殊處理

1. 主庫重啟 → Memory 表清空。
2. 從庫不知情，繼續提供舊資料（資料不一致）。
3. 主庫首次使用該表時，自動寫入 DELETE FROM 至 Binlog，從庫同步清空。
4. 風險窗口： 重啟 ~ 首次使用間隙，從庫資料過期。
5. 解決： 主庫 --init-file 啟動時自動重建 Memory 表，風險窗口歸零。

適用場景判斷樹

資料是否允許遺失（重啟/故障）？
├─ 否 → ❌ 禁用 MEMORY，改用 InnoDB/NDB
└─ 是 → 訪問模式為何？
    ├─ 純快取/Session/暫存 → ✅ MEMORY 首選
    ├─ 讀多寫少、需持久化 → ⚠️ 評估 MyISAM/InnoDB + 大記憶體緩衝池
    └─ 高並發寫入、混合負載 → ❌ MEMORY 表鎖瓶頸，改用 InnoDB/NDB

效能測試預覽（詳細見第二部分）

• 寫入：InnoDB ≈ 5× MyISAM ≈ 6× Memory
• 讀取：三引擎接近，Memory 微幅領先
• .NET DataTable 完勝（進程內零開銷）

Memory 引擎是把「雙刃劍」：用對場景（快取、Session、可重建暫存資料）能發揮極致速度；用錯場景（核心業務資料、高並發寫入、需持久化）將釀成災難。選型前請嚴格套用上述判斷樹，並做好容量規劃與監控告警。