關於 MySQL INSERT 的真實效能，相信大多數開發者都難以給出準確答案。網路上雖然流傳著許多總結文章，但「紙上得來終覺淺」，最終還是得靠實際數據說話。筆者近期針對插入 1000 萬筆資料進行了系統性測試，涵蓋 MyISAM、InnoDB、NDB Cluster 三種儲存引擎，並在單執行緒、百執行緒、千執行緒等不同併發場景下驗證表現，以下為完整測試紀錄與核心發現。

測試環境與參數設定

• 資料量：各測試案例均插入 1000 萬筆
• 表結構：10 個 VARCHAR(255) 欄位，內容為 32 位 UUID，僅有主鍵，無其他索引
• 事務：測試全程未使用事務
• 硬體：虛擬機環境，NDB 為避免資源爭用採用三台獨立宿主機
• 版本：NDB 6.x、MySQL Proxy 0.8.x

十大測試案例

1. MyISAM 單執行緒
2. InnoDB 單執行緒，開啟 innodb_flush_log_at_trx_commit=1
3. InnoDB 單執行緒，關閉 innodb_flush_log_at_trx_commit=0
4. MyISAM 100 執行緒、100 連線池
5. InnoDB 100 執行緒、100 連線池，關閉 Log
6. MyISAM 1000 執行緒、1000 連線池
7. InnoDB 1000 執行緒、1000 連線池
8. NDB Cluster（3 Node、3 副本）單執行緒，經 MySQL Proxy 負載均衡
9. NDB Cluster 100 執行緒、100 連線池，經 Proxy
10. NDB Cluster 1000 執行緒、1000 連線池，經 Proxy

核心測試結論

MyISAM：高併發下的效能王者

在壓力測試中 MyISAM 優勢極為明顯。100 執行緒曲線最低（耗時最短），1000 執行緒緊隨其後，且效能呈現近乎線性擴展。得益於表鎖機制與無事務開銷，純寫入場景下 MyISAM 表現強勁。

InnoDB：innodb_flush_log_at_trx_commit 參數決定生死

• 開啟 Log（=1）：單執行緒效能近乎墊底，每次提交皆需刷盤，IO 開銷巨大。
• 關閉 Log（=0）：效能大幅提升可接受，但高併發下效能下降明顯，曲線非線性，受限於行鎖與 Undo Log 管理。

NDB Cluster：記憶體架構的雙面刃

• 資料全放記憶體，預期效能應優異，但單執行緒卻墊底，推測 MySQL Proxy 引入額外延遲。
• 三副本同步寫入消耗大量記憶體，預設配置易耗盡，需手動調整 DataMemory。
• 亮點：100 與 1000 執行緒曲線幾乎重合，展現極佳的併發穩定性。

延伸思考：NoSQL 的衝擊

同條件下 MongoDB 單執行緒寫入速度是 MySQL 的 3 倍，得益於索引常駐記憶體與無 Schema 設計。若加入查詢對比，差距或將更大。雲原生時代，關係型資料庫在海量資料、高併發、強一致性、災備之間的取捨愈發艱難，MySQL 核心優勢逐漸收斂至「完整事務支援」單一項目。

建議：純寫入、高併發、可容忍資料遺失場景首選 MyISAM；需 ACID 保障則 InnoDB 配合 innodb_flush_log_at_trx_commit=2 平衡效能與安全；NDB 適合極高可用、記憶體充足的分散式場景，但需精細調優 Proxy 與記憶體參數。