MySQL 儲存引擎選型深度指南：InnoDB vs MyISAM 核心差異與決策矩陣

決策前五問

1. 需要外鍵約束嗎？
2. 需要事務（ACID）嗎？
3. 需要全文索引嗎？
4. 查詢模式為何？（讀多寫少 / 讀寫均衡 / 複雜關聯）
5. 資料量多大？（GB / TB 級）

核心差異總覽

適用場景建議

✅ 選 MyISAM 的場景

• 讀多寫少、以 SELECT COUNT(*)、ORDER BY 為主的報表/日誌/統計表。
• 資料可重建、不需事務、無外鍵（如點擊流、爬蟲暫存）。
• 需快速複製檔案分發給下游（Merge 引擎配合橫向分表）。
• 資料量極大（TB 級），InnoDB 空間成本過高、恢復時間不可接受。

✅ 選 InnoDB 的場景

• 核心業務：訂單、帳戶、庫存，需事務、外鍵、高併發寫入。
• 資料不可遺失，需快速 PITR（Point-In-Time Recovery）。
• 主鍵查詢佔比高，受益於叢集索引。
• 混合讀寫、行鎖減少衝突。

實戰經驗：大型平台為何仍大量用 MyISAM？

平台承載數百 TB、日均 10 億+ PV，核心業務用 InnoDB，但 70% 表為 MyISAM。原因：

1. 讀多寫少場景佔多數，MyISAM 讀效能更優、索引壓縮省記憶體。
2. 誤 UPDATE 發生時，MyISAM 只需複製 .MYD/.MYI 檔案秒級恢復；InnoDB 需邏輯備份還原，耗時數小時。
3. COUNT(*)、ORDER BY 佔 SQL 總量 60%+，MyISAM 極快且不鎖表。
4. 下游數據部門需定期拉取表檔案，MyISAM 直接給 .frm/.MYD/.MYI 即可；InnoDB 需導出 SQL。
5. Merge 引擎支援海量日誌表橫向分表聚合查詢，開發效率極高。

架構層面：分庫分表、讀寫分離、緩存層吸收寫入壓力，彌補 MyISAM 寫入弱勢。

轉換指南

-- MyISAM -> InnoDB
ALTER TABLE tbl ENGINE=InnoDB;

-- InnoDB -> MyISAM（需先移除外鍵）
ALTER TABLE tbl DROP FOREIGN KEY fk_name;
ALTER TABLE tbl ENGINE=MyISAM;

大表轉換極慢且鎖表，生產環境必須用 pt-online-schema-change 或 gh-ost。

配置關鍵參數

總結：沒有銀彈，只有適合

根據業務特性、資料量、運維能力、恢復目標（RPO/RTO）綜合選型。混合部署是常態：核心交易 InnoDB，海量日誌/統計 MyISAM，全文搜尋另上 Elasticsearch。