在 MySQL 架構中，存儲引擎是負責數據存儲、索引構建與查詢執行的核心組件。雖然 MySQL 支援多種引擎，但在生產環境中最常被討論、也是決策關鍵的，莫過於 MyISAM 與 InnoDB。雙引擎各有設計哲學與適用場景，並無絕對優劣之分，關鍵在於業務需求與架構特性的匹配度。本文將從存儲架構、事務支援、鎖機制、效能特徵等維度進行深度對比，助您做出明智選擇。
MyISAM 採用「表即文件」的直觀設計，每張表對應三個獨立文件：
.frm：表結構定義（所有引擎通用）.MYD (MYData)：數據文件.MYI (MYIndex)：索引文件此結構賦予了 MyISAM 極佳的可移植性：跨平台遷移、單表備份/恢復僅需複製對應文件即可。且支援數據壓縮（myisampack），存儲空間佔用較小，適合唯讀或以讀為主的場景。
InnoDB 將所有表數據與索引存儲於統一的表空間中（系統表空間 ibdata1 或獨立表空間 .ibd），大小僅受限於作業系統文件上限（通常 2GB+）。雖佔用更多記憶體與磁碟空間，但其在主記憶體中構建的緩衝池可高速緩存數據與索引，是高併發、大數據量場景的效能基石。
| 特性維度 | MyISAM | InnoDB |
|---|---|---|
| 事務支援 (ACID) | 不支援，僅保證單次查詢原子性 | 完整支援 Commit/Rollback/Crash Recovery |
| 鎖粒度 | 僅支援表鎖 | 支援行鎖（主鍵條件下）與表鎖，大幅提升併發 |
| 外鍵約束 | 不支援 | 支援，保證引用完整性 |
| 全文索引 | 原生支援 | 5.6+ 版本支援，早期需配合 Sphinx |
| AUTO_INCREMENT | 允許聯合索引中非首列 | 必須包含該列的單獨索引 |
| COUNT(*) 無 WHERE | 極快（元數據儲存行數） | 需全表掃描，較慢 |
| 崩潰恢復 | 無，易損壞需修復 | 基於 Redo/Undo Log 自動恢復 |
InnoDB 設計目標直指大容量數據庫系統，其 CPU 利用率與併發處理能力遠超同類磁盤引擎。自 MySQL 5.5 起，InnoDB 已成為預設引擎，這非偶然。對於大多數現代應用，推薦採用 InnoDB + 適當緩存策略（如 Redis/Memcached 緩存熱點查詢） 的組合，可同時兼顧事務安全、高併發效能與查詢響應速度。
總結：若您的應用涉及金融交易、用戶核心數據或高併發寫入，InnoDB 是不二之選；純分析查詢、日誌歸檔等側重讀取且容忍數據風險的場景，MyISAM 仍具輕量優勢。理解業務本質，方能選型精準。
