MySQL 服務意外停止 1067 錯誤三大根因與標準化修復流程

Windows 事件日誌記錄 Event ID 7034: MySQL 服務意外停止，嘗試啟動報 1067 錯誤。經大量實戰驗證，根因集中於三類，修復流程標準化如下。

根因一：my.ini 配置錯誤（最高發）

• 修改 my.ini 後未備份，參數拼寫錯誤、路徑不存在、編碼衝突
• 修復：以預設模板（my-large.ini 等）覆蓋 my.ini 重啟驗證，再逐項套用自訂參數

根因二：服務登入帳號密碼失效

1. 電腦管理 → 本地使用者 → MySQL 服務帳號（通常 mysqladmin）
2. 重設密碼（勿勾選「下次登入必須變更密碼」）
3. 服務管理器 → MySQL → 內容 → 登入 → 此帳號 → 輸入新密碼 → 確定
4. 重啟服務

根因三：殘留 Data 目錄導致初始化衝突

• 重裝/升級時直接覆蓋舊 Data 目錄，導致 ibdata1、ib_logfile*、系統表與新版本不兼容
• 修復：
  1. 備份 Data 目錄（若需保留資料）
  2. 完全刪除安裝目錄
  3. 重新安裝 MySQL（生成乾淨 Data）
  4. 若需舊資料，用 mysqldump 匯出再匯入，或啟動舊版本匯出 SQL

標準化排查 SOP

1. 事件檢視器 → 系統日誌 → 找 MySQL 錯誤詳情
2. 命令列執行 mysqld --console 觀察即時輸出錯誤行
3. 檢查 Data 目錄下 .err 錯誤日誌
4. 依序驗證上述三大根因
5. 必要時 mysqld --remove 移除服務重裝

預防措施

• my.ini 納入版本控制，變更留存備份
• 服務帳號設為「密碼永不過期」或使用專用受管服務帳號
• 重裝前務必完整備份並驗證 mysqldump 可用性
• 建立「MySQL 服務異常標準處置單」文件化流程