選型鐵律
無特殊理由，一律 InnoDB。 它是功能最全、生態最成熟、性能最均衡的通用引擎。只有當業務有明確、不可替代的特殊需求時，才考慮其他引擎。
決策樹：三個核心問題
- 需要事務 (ACID) 嗎？ 是 → InnoDB/XtraDB (唯一穩定選擇)。
- 需要線上熱備份嗎？ 是 → InnoDB (xtrabackup 非阻塞備份)。否 → 可考慮 MyISAM/Archive。
- 崩潰恢復時間敏感嗎？ 是 → InnoDB (Redo Log 快速恢復)。MyISAM 恢復慢且易損壞。
上述任一答案為「是」，選型即鎖定 InnoDB。
特殊場景替代方案
1. 極致寫入吞吐、無事務、可容忍丟數據 → MyISAM / Archive
- 日志、監控、埋點、流水號生成。
- MyISAM：表鎖、無事務、全文索引 (舊版本)、空間較小。
- Archive：極高壓縮、只支援 INSERT/SELECT、無索引、適合歸檔。
分析查詢分離模式：主庫寫入 (MyISAM/Archive) → 複製到從庫/數據倉庫 (InnoDB/ClickHouse) 執行分析查詢，互不干擾。
2. 唯讀/極少寫、空間敏感、可容忍崩潰修復 → MyISAM
- 配置表、字典表、郵編表、靜態分類。
- 風險提示：MyISAM 不保證數據落盤 (依賴 OS fsync)，掉電易丟數據、索引損壞。必須壓測驗證崩潰恢復時間。
3. CD-ROM/唯讀分發介質 → MyISAM 壓縮表
myisampack 壓縮，唯讀、跨平台複製、空間極致節省。
4. 地理空間搜尋 (MySQL 5.7 前) → MyISAM
- 5.7+ InnoDB 已支援空間索引 (R-Tree)，新專案首選 InnoDB。
5. 大數據量單機 > 3TB → InnoDB + 分區/分片
- 合理硬體 (NVMe、大內存)、
innodb_buffer_pool_size 佔 70% 內存、分區表管理歷史數據。
- 10TB+ 級別轉向數據倉庫：Infobright (列存)、ClickHouse、TokuDB (Fractal Tree 索引、高壓縮)。
避坑十條
- 嚴禁混合引擎：備份、事務邊界、參數調優複雜度指數級上升。
- 不輕信「MyISAM 更快」：聚簇索引命中、熱數據全內存時 InnoDB 更快。
- 全文搜尋 → InnoDB + Elasticsearch/Sphinx：勿為全文索引選 MyISAM。
- 壓測必拔電：崩潰恢復驗證是選型最後一道關卡。
- 主鍵設計決定生死：InnoDB 主鍵過大 = 所有索引膨脹 = 性能災難。
- 讀寫分離架構：主庫 InnoDB 寫入，從庫 InnoDB 讀取，統一引擎最省心。
- 監控關鍵指標：
Innodb_buffer_pool_reads、Innodb_row_lock_waits、Innodb_deadlocks。
- 定期 OPTIMIZE TABLE：InnoDB 重建表消除碎片，回收空間。
- 備份策略分層：物理全備 (xtrabackup) + 增量備份 + 邏輯備份 (mysqldump 核心小表)。
- 版本升級測試：新版本優化器行為變化可能導致執行計劃劣化，必須預演。
