核心原則
除非有明確、不可替代的理由，否則預設選擇 InnoDB。 它是目前功能最完整、生態最成熟、性能最均衡的通用引擎。
決策維度對比
| 維度 | InnoDB | MyISAM | Archive | Memory |
|---|
| 事務支援 | ✅ ACID | ❌ | ❌ | ❌ |
| 行級鎖/高併發 | ✅ | ❌ 表鎖 | ❌ 表鎖 | ✅ 表鎖(內存) |
| 熱備份 | ✅ xtrabackup | ❌ 需鎖表 | ❌ | ❌ 數據易失 |
| 崩潰恢復速度 | ✅ 快 | ❌ 慢/易損壞 | ❌ | ❌ 需重載 |
| 全文索引 | ✅ 5.6+ | ✅ 早期優勢 | ❌ | ❌ |
| 地理空間索引 | ✅ 5.7+ | ✅ 唯一支援 | ❌ | ❌ |
| 壓縮/唯讀 | ✅ 頁壓縮 | ✅ myisampack | ✅ 高壓縮 | ❌ |
| 空間佔用 | 較大 | 較小 | 極小 | 內存 |
典型業務場景選型
1. 核心交易/訂單系統 → InnoDB
- 強事務一致性、外鍵約束、高併發寫入、崩潰快速恢復。
2. 日志/監控/埋點寫入密集 → MyISAM 或 Archive
- 無事務需求、極高寫入吞吐、數據可容忍少量丟失（MyISAM）或只寫不改（Archive）。
- 分析查詢分離策略：主庫寫入，從庫/數據倉庫分析；或按時間分表，歷史表唯讀查詢。
3. 唯讀/配置/字典表 → MyISAM (可選)
- 極少寫入、可容忍崩潰修復時間、對空間敏感。警示：MyISAM 不保證數據落盤，掉電易丟數據。
4. CD-ROM/唯讀分發介質 → MyISAM 壓縮表
5. 大數據量單機 > 3TB → InnoDB + 合理分區/分片
- MyISAM 崩潰恢復是噩夢。InnoDB 配合合理硬體、IO 規劃、分區表支撐 TB 級單機。
- 10TB+ 考慮數據倉庫方案：Infobright、ClickHouse、TokuDB (Fractal Tree 索引)。
避坑指南
- 不要混合多種引擎：增加備份、參數調優、事務邊界複雜度，引入潛在 Bug。
- 不輕信「MyISAM 比 InnoDB 快」：聚簇索引命中、熱數據全內存場景下，InnoDB 往往更快。
- 壓測驗證崩潰恢復：拔電測試是檢驗引擎可靠性的唯一標準。
- 全文搜尋首選 InnoDB + Sphinx/Elasticsearch：勿因全文索引選 MyISAM，架構複雜度不值得。
總結
InnoDB 是「最安全的預設選擇」。只有在極少數特定場景（唯讀壓縮、極致寫入吞吐無事務、地理空間舊版本依賴）下，才考慮 MyISAM、Archive 等專用引擎。選型前先問三個問題：需不需要事務？需不需要熱備份？崩潰恢復時間窗口多長？
