MySQL 存儲引擎深度對比：InnoDB vs MyISAM 選型指南

核心差異速覽

關鍵細節深度解析

1. 鎖機制的實際影響

InnoDB 行級鎖基於索引生效：WHERE pk = 1 走主鍵索引僅鎖定該行；WHERE name LIKE '%abc%' 全表掃描將升級為表鎖。MyISAM 永遠是表鎖，讀寫互斥，高並發寫入性能瓶頸明顯。

2. COUNT(*) 性能陷阱

-- InnoDB 必須全表掃描聚合
SELECT COUNT(*) FROM huge_table;  -- 慢

-- MyISAM 直接讀取元數據
SELECT COUNT(*) FROM huge_table;  -- 极快

-- 帶 WHERE 條件時兩者一致
SELECT COUNT(*) FROM huge_table WHERE status = 1;

3. 存儲結構與空間佔用

• MyISAM：數據與索引分離，索引可壓縮（myisampack），內存利用率高，適合只讀/讀多寫少場景；
• InnoDB：索引與數據聚簇存儲（B+ 樹葉子節點即數據），無壓縮（除非啟用 COMPRESSED 行格式），體積通常較大 20%-30%。

4. 運維視角的差異化體驗

選型決策矩陣

✅ 選擇 InnoDB 的場景

• 核心業務涉及事務（訂單、支付、庫存扣減）；
• 需要外鍵約束保證引用完整性；
• 高並發讀寫混合，依賴行級鎖降低衝突；
• 要求崩潰安全、自動恢復能力。

✅ 選擇 MyISAM 的場景

• 日誌、統計、報表類「寫一次、讀多次」數據；
• 全文搜索依賴（5.6 前版本）；
• 運維團隊偏好文件級備份/恢復/分發；
• 單表超大、不需事務、追求極致讀性能與壓縮比。

💡 混合部署策略

生產環境常採用「核心表 InnoDB + 非核心大表 MyISAM」混合架構，配合分庫分表、讀寫分離，在事務安全與查詢性能間取得平衡。MySQL 8.0 已大幅優化 InnoDB 只讀性能與壓縮能力，新項目傾向全 InnoDB 部署更為普遍。

避坑指南

1. 不要在 InnoDB 大表上執行無條件 DELETE FROM table，使用 TRUNCATE 或分批刪除；
2. InnoDB 表避免使用 LOAD TABLE FROM MASTER，該命令不支持；
3. 監控 Innodb_row_lock_waits 與 Table_locks_waited，及時發現鎖爭用熱點；
3. MyISAM 表定期執行 OPTIMIZE TABLE 碎片整理，維持查詢性能。