MyISAM 與 InnoDB 是 MySQL 歷史上最核心的兩大儲存引擎。雖然 5.5+ InnoDB 成為預設，但 MyISAM 在特定場景仍有不可替代優勢。本文從架構、鎖、事務、索引、檔案、安全性、指令六大維度深度對比，給出明確選型決策樹。
| 維度 | MyISAM | InnoDB | 影響 |
|---|---|---|---|
| 事務 | ❌ 不支援 | ✅ 完整 ACID | 資金/訂單/庫存必選 InnoDB |
| 鎖粒度 | 表級鎖 | 行級鎖 (含意向鎖、間隙鎖、Next-Key Lock) | 高併發寫入 InnoDB 吞吐量碾壓 |
| 外鍵 | ❌ | ✅ | 資料完整性約束靠應用層 vs 資料庫層 |
| 全文索引 | ✅ (5.6 前獨佔) | ✅ (5.6+) | 新版無差異，舊版 MyISAM 唯一選擇 |
| 檔案結構 | .frm (結構) + .MYD (資料) + .MYI (索引) | 表空間 (ibdata1 系統表空間 + .ibd 獨立表空間) | MyISAM 跨平台複製檔案即遷移；InnoDB 需邏輯備份/傳輸表空間 |
| 崩潰恢復 | 極難 (需 myisamchk 修復，易損資料) | Redo/Undo Log 自動恢復，保證一致性 | 生產環境核心指標 |
| MVCC | ❌ | ✅ (一致性非鎖定讀) | 讀寫不阻塞，讀取歷史版本 |
| 聚簇索引 | ❌ (堆表，主鍵非聚簇) | ✅ (主鍵即聚簇索引，資料與主鍵同存) | 主鍵查詢極快，二級索引需回表 |
| 行鎖升級 | 無 (只有表鎖) | 無法確定掃描範圍時退化為表鎖 (如 LIKE '%...'、無索引條件) | 惡意 SQL 仍可拖垮 InnoDB |
業務是否涉及資金/核心資產/需嚴格一致性？ → InnoDB (無腦首選)
純讀/多讀少寫/靜態報表/日誌/全文搜尋 (舊版)？ → MyISAM 可考慮
高併發寫入/更新/刪除？ → InnoDB (行鎖 + MVCC)
跨平台直接複製檔案遷移？ → MyISAM (cp .MYD/.MYI 即可)
不確定/通用 OLTP？ → InnoDB (預設最佳實踐)
-- 1. 查看表引擎 (三種方式)
SHOW CREATE TABLE tbl_name;
SHOW TABLE STATUS FROM db_name WHERE Name = 'tbl_name';
mysqlshow -u user -p pwd --status db_name tbl_name
-- 2. 修改引擎 (會重建表，大表慎用，鎖表久)
ALTER TABLE tbl_name ENGINE = InnoDB;
-- 3. 修改預設引擎 (僅影響後續 CREATE TABLE)
-- 永久：my.cnf [mysqld] default-storage-engine=InnoDB
-- 會話級：
SET default_storage_engine = InnoDB;
-- 或舊語法
SET table_type = InnoDB;
SHOW VARIABLES LIKE 'table_type';InnoDB 是現代 MySQL 的基石：事務、行鎖、MVCC、崩潰安全、聚簇索引、自適應雜湊索引、變更緩衝區、線程池 (企業版) 等特性專為 OLTP 設計。
MyISAM 退居特定場景：唯讀壓縮表 (myisampack)、全文搜尋舊版本、極簡嵌入式、跨平台檔案級遷移。
鐵律： 新專案**預設 InnoDB**，除非有極強理由 (且經 DBA 評估) 才用 MyISAM。混合引擎部署增加運維認知負擔，不推薦。
