記一次阿里雲 Windows Server MySQL 1067 錯誤：InnoDB 記憶體不足導致服務啟動失敗

MySQL 1067 錯誤排查實錄：InnoDB 記憶體配置過大導致服務無法啟動

一、現象描述

• 環境：阿里雲 Windows Server 2008 R2
• 安裝 MySQL 後配置「並發連接數 = 500」
• 啟動服務失敗，Windows 事件檢視器記錄：
  Unknown/unsupported storage engine: InnoDB

二、誤區與正確方向

網路上常見建議「將 InnoDB 改為 MyISAM」，但這是治標不治本。InnoDB 是現代 MySQL 核心引擎，支援事務、行級鎖、外鍵，**不應輕易捨棄**。

三、根因分析

參考 StackOverflow 討論，錯誤實為 記憶體不足導致 InnoDB 無法分配緩衝池。Windows 服務啟動時，InnoDB 依配置參數（innodb_buffer_pool_size、innodb_log_buffer_size、執行緒堆疊等）預分配記憶體。若實體記憶體 + 虛擬記憶體不足，InnoDB 初始化失敗，報錯「unsupported storage engine」。

「並發連接數 = 500」會衍生大量執行緒堆疊與連接緩衝區，加劇記憶體壓力。

四、解決方案

1. 降低並發配置：將「並發連接數」從 500 降至 100（或依實際記憶體評估）
2. 調整 InnoDB 核心參數（my.ini）：
   innodb_buffer_pool_size = 128M # 視記憶體而定，建議 50-70%
innodb_log_buffer_size = 8M
thread_stack = 192K
3. 增加虛擬記憶體：系統屬性 → 進階 → 效能設定 → 進階 → 虛擬記憶體變更
4. 升級實例規格：根本解決為增加實體記憶體

五、驗證步驟

net start mysql
# 或
mysqld --console  -- 直接前景執行觀察錯誤輸出

調整後服務順利啟動，錯誤消失。

六、經驗總結

• Windows 下 MySQL 記憶體管理較 Linux 敏感，預分配機制易觸發 1067
• 安裝精靈的「並發配置」實際修改多個參數，需謹慎評估
• 生產環境建議 Linux + 專用實例，避開 Windows 記憶體碎片與服務管理限制
• 錯誤訊息「unsupported storage engine」實為初始化失敗的副作用，非引擎真不支援