核心差異速覽
| 維度 | MyISAM | InnoDB |
|---|
| 事務支持 | ❌ 不支持 | ✅ 完整 ACID |
| 鎖粒度 | 表級鎖 | 行級鎖 |
| 外鍵約束 | ❌ 不支持 | ✅ 支持 |
| 全文索引 | ✅ 早期支持 | ✅ 5.6+ 支持 |
| 數據文件結構 | 索引與數據分離 | 聚簇索引（數據即索引） |
| 崩潰恢復 | ❌ 依賴修復工具 | ✅ Redo/Undo Log 自動恢復 |
| MVCC | ❌ | ✅ 多版本並發控制 |
關鍵技術細節差異
1. COUNT(*) 性能
- MyISAM：元數據直接存儲行數，
COUNT(*) 瞬時返回
- InnoDB：需掃描聚簇索引或輔助索引統計行數，
WHERE 條件下兩者一致
2. AUTO_INCREMENT 行為
- InnoDB：自增列必須為索引首列（單列索引或聯合索引首列）
- MyISAM：允許自增列在聯合索引非首列位置
3. DELETE 表數據
- MyISAM：
DELETE FROM table 重建表，極快
- InnoDB：逐行標記刪除，不釋放空間，需
TRUNCATE 或 OPTIMIZE TABLE
4. 主從復制相關
- LOAD TABLE FROM MASTER：僅 MyISAM 支持，InnoDB 需轉換引擎後導入
5. 鎖升級陷阱
InnoDB 無法確定掃描範圍時會退化為表鎖，如：
UPDATE table SET num=1 WHERE name LIKE '%aaa%'; -- 無法用索引，鎖全表
選型決策矩陣：何時選 MyISAM？
雖然 InnoDB 是 5.7+ 默認引擎，但在特定場景 MyISAM 仍有優勢：
✅ 適合 MyISAM 的場景
- 純讀/讀多寫少：日誌、統計、報表類數據，MyISAM 讀性能優於 InnoDB
- 全文搜索依賴：早期版本唯選擇（5.6+ InnoDB 已支持）
- 極速 COUNT(*) 需求：無 WHERE 條件的全表計數高頻場景
- 文件級備份/遷移：直接複製
.frm/.MYD/.MYI 文件即可，跨實例遷移極快
- Merge 引擎分片：海量日志表通過 Merge 引擎邏輯分片，
COUNT(*) 自動聚合
- 只讀副本分發：直接發送文件給下游部門，無需導出 SQL
✅ 必須選 InnoDB 的場景
- 事務一致性要求：訂單、支付、庫存等核心業務
- 高併發寫入：行級鎖 + MVCC 支持更高並發吞吐
- 外鍵約束：數據完整性由數據庫層面保證
- 崩潰安全：掉電自動恢復，無需人工干預
- 主從複製可靠性：基於 Redo Log 的復制更穩定
架構層面的權衡
存儲結構差異
- MyISAM：
.MYD 數據文件 + .MYI 索引文件，索引壓縮，內存效率高
- InnoDB：
.ibd 聚簇索引（主鍵順序存儲數據），輔助索引葉子存主鍵值，體積較大
備份恢復策略
| 操作 | MyISAM | InnoDB |
|---|
| 物理備份 | 複製文件極快 | 需 XtraBackup/InnoDB Hot Backup |
| 邏輯備份 | mysqldump 較慢 | mysqldump 單線程慢，建議 mydumper |
| 單表恢復 | 文件級覆蓋秒級 | 需導入 SQL 或傳輸表空間 |
混合部署最佳實踐
- 核心業務表：強制 InnoDB（事務、外鍵、高併發）
- 日志/統計/報表表：MyISAM（快速 COUNT、文件級遷移、Merge 分片）
- 只讀歷史歸檔表：MyISAM 壓縮表
myisampack 極致壓縮比
- 全文搜索表：5.6+ 統一 InnoDB，簡化維護
避坑指南
- 不要因「MyISAM 讀快」就全庫用 MyISAM：寫入鎖表會導致嚴重並發阻塞
- InnoDB 表必須顯式定義主鍵：無主鍵會生成 6 字節隱藏列，輔助索引引用開銷大
- 主鍵選擇自增整數：UUID/字符串主鍵導致聚簇索引分裂、輔助索引膨脹
- 大批量 DELETE 用 TRUNCATE 或分批：InnoDB 逐行刪除產生大量 Undo Log
總結
MySQL 8.0 已移除 MyISAM 相關優化投入，InnoDB 覆蓋 99% 核心場景。僅在「極致讀性能、文件級運維、Merge 分片」三大鐵律場景下考慮 MyISAM，其餘一律 InnoDB。架構設計應以 InnoDB 為基準，MyISAM 作為特定場景的戰術補充。
