MySQL 儲存引擎特性全解析：InnoDB vs MyISAM 選型指南

MySQL 儲存引擎特性全解析

MySQL 的插件式儲存引擎架構讓開發者能根據業務特性選擇最適合的底層儲存方式。本文系統整理主流引擎核心特性對比、適用場景及選型決策樹，助您在架構設計階段做出最優決策。

核心引擎特性對比表

兩大主流引擎深度剖析

MyISAM：讀密集、非事務場景的經典選擇

• 檔案結構：每表三檔 .frm(定義)、.MYD(資料)、.MYI(索引)，支援資料/索引分離存放分散 I/O。
• 優勢：全表鎖下讀取極快、支援全文索引、壓縮唯讀表 (myisampack)、修復工具完善 (myisamchk)。
• 劣勢：無事務、無行鎖、崩潰易損壞需人工修復、並發寫入效能差。
• 適用：日誌分析、資料倉儲唯讀查詢、CMS 內容管理、非關鍵中繼資料。

InnoDB：OLTP 核心業務的標準之選

• 核心優勢：完整 ACID 事務、行級鎖高並發、叢集索引主鍵查詢極快、崩潰安全自動恢復、外鍵維護參考完整性。
• 代價：寫入開銷大、空間佔用高 (約 2-3×MyISAM)、全文索引 5.6 才支援、計數 COUNT(*) 需全表掃描。
• 適用：電商訂單、金融帳務、用戶中心、高並發讀寫混合核心業務。

其他特色引擎適用場景

• Memory (HEAP)：純記憶體暫存表，適合查找表、中間結果緩存、Session 存儲；重啟資料消失，僅支援 Hash 索引 (5.6+ 支援 B-Tree)。
• Archive：極高壓縮比、僅支援插入/全表掃描，適合海量歷史日誌、審計軌跡、合規歸檔。
• CSV：純文本逗號分隔，方便外部工具交換資料，不支援索引。
• Federated：遠端資料庫映射，跨實例查詢，網路延遲敏感，慎用於高頻路徑。
• NDB Cluster：分散式高可用叢集，適用電信級計費、即時遊戲狀態。

選型決策樹：三步鎖定最佳引擎

1. 需要事務嗎？ 是 → InnoDB (或 NDB)；否 → 進入第 2 步。
2. 純唯讀/海量歸檔？ 是 → Archive/MyISAM；否 → 進入第 3 步。
3. 極高速查找、資料可重建？ 是 → Memory；否 → 預設 InnoDB (5.7+ 預設引擎)。

混合部署最佳實踐

單一實例內不同表可指定不同引擎：

CREATE TABLE orders (...) ENGINE=InnoDB;
CREATE TABLE access_logs (...) ENGINE=Archive;
CREATE TABLE lookup_codes (...) ENGINE=Memory;

配合 innodb_file_per_table=ON 獨立表空間，便於單表備份、遷移、碎片整理。

避坑提醒

• MyISAM 表損壞後 REPAIR TABLE 可能丟資料，InnoDB 依賴 Redo Log 自動恢復更可靠。
• Memory 引擎表重啟清空，切勿存儲不可重建的業務資料。
• 5.7 以前版本預設 MyISAM，建立表時顯式指定 ENGINE=InnoDB 避免踩坑。

總結

理解儲存引擎特性是 MySQL 架構優化的基石。核心業務首選 InnoDB，輔以 Archive 歸檔、Memory 熱點查找，構建分層儲存體系，在一致性、效能、成本間取得最佳平衡。