MySQL 終止支援（EOL）：為何您必須立即檢查您的版本

1. MySQL 生命週期結束（EOL）是什麼？為什麼你應該立即檢查

MySQL EOL 是什麼？從基礎說明

MySQL 是一個廣泛使用的開源關聯式資料庫管理系統，已在全球的網路應用程式和商業系統中部署。然而，並非所有版本都會永續支援。

MySQL 也有一個事件稱為 「生命週期結束（EOL）」。這標示了其開發者（Oracle Corporation）停止對該版本提供支援（如 安全更新和錯誤修正）的日期。

例如，MySQL 5.7 在 2023 年 10 月結束支援。像這樣的 EOL 資訊至關重要，因為它直接影響你的系統安全與未來可行性。

「我沒意識到已經 EOL」的危險

許多開發者和運維工程師對升級 MySQL 持謹慎態度。他們可能會想「它很穩定，我們就保持不變」，但繼續使用已經 EOL 的版本會帶來重大風險。

具體而言，以下風險適用：

• 安全漏洞不再修補
• 與作業系統或其他軟體的相容性喪失
• 供應商支援變得不可用
• 新開發者可能會避免使用，導致維護成本上升

為了避免這些風險，必須 定期檢查公司使用的 MySQL 版本以及該版本是否仍受支援。

瞭解支援資訊可預防「事故」

對於在關鍵任務系統中使用 MySQL 的企業而言，「我們未注意到已經 EOL」 的情況可能會在之後導致重大事故或安全漏洞。

因此，瞭解你的 MySQL 版本的 支援生命週期並在 EOL 前規劃升級或遷移 是維持穩定運營的關鍵。

下一節列出哪些版本已達 EOL 以及時間。

2. MySQL 版本支援結束摘要（EOL 資訊）

瞭解主要 MySQL 版本及其 EOL 日期

MySQL 多年來持續進行版本升級，每個版本都有明確的支援期間。以下列出主要版本及其官方公告的 EOL（生命週期結束日期）。

[Version-by-Version EOL Table]

※日期基於 Oracle 及各雲端服務供應商的公開資訊。

MySQL 5.5（支援結束於 2018）

MySQL 5.5 於 2010 年發布，並被許多網路應用程式採用。然而，它於 2018 年 12 月 3 日結束支援。不再提供安全修補程式或錯誤修正，因此如果仍在使用，必須立即遷移。

MySQL 5.6（支援結束於 2021）

MySQL 5.6 透過提升效能與新增功能而受到歡迎，但它於 2021 年 2 月 5 日達到 EOL。如果你的環境使用此版本，現在已 不受支援且風險極高。

MySQL 5.7（支援結束於 2023 年 10 月）

MySQL 5.7 已被許多企業系統使用多年，但它於 2023 年 10 月 21 日結束支援。許多系統仍在執行此版本，且遷移的公司數量正在增加。現在的重點轉向驗證相容性與遷移資料。

MySQL 8.0（Premier 支援將於 2025 年 4 月結束）**

MySQL 8.0 是目前的穩定版本，但其 Premier 支援預定於 2025 年 4 月結束。之後建議延伸支援或遷移至 LTS 版本。新推出的 MySQL 8.4 LTS（於 2024 年發布）正受到長期穩定運營的關注。

事前規劃需要 EOL 資訊

如上所示，每 MySQL 版本都有明確的 EOL，且必須規劃遷移。檢查你系統中使用的版本，並將心態從「仍可使用」轉為 「我們什麼時候遷移？」。

3. 支援結束時會發生什麼？EOL 帶來的風險

在支援結束後使用版本會帶來極高風險

當 MySQL 版本到達 EOL（終止生命週期）時，所有官方支援——包括 安全更新、錯誤修正與功能改進——將完全停止。這意味著 Oracle 將不再提供任何支援。

即使它看似正常運作，嚴重風險仍潛伏於表面之下。尤其對於連網的網頁伺服器或核心業務系統，這些風險不可忽視。

被忽略的安全漏洞

最關鍵的風險是 新發現的漏洞將不會被修補。攻擊者往往會針對已知缺陷的 EOL 版本進行攻擊。

而且由於 MySQL 廣泛使用，它成為 極具吸引力的目標。EOL 後任何發現的漏洞都將保持未修補，防禦極度有限。

🔒 無緩解措施 = 永遠被針對的狀態。

違反法規或安全標準的風險

在企業與公共機構中，遵守資訊安全標準（如 ISMS 或 PCI DSS）已成為越來越多的要求。這些標準通常禁止使用 支援已結束的軟體。

換句話說，使用 EOL 版本的 MySQL 可能導致審計發現或損害與合作夥伴的信任。

與作業系統或其他軟體的不相容問題

EOL 版本往往缺乏 與目前作業系統或其他軟體的驗證相容性，可能引發意外故障或性能下降。例如，在作業系統更新後，MySQL 可能無法啟動或性能嚴重下降。

這可能導致 緊急修復工作或最壞情況的服務中斷。

技術債累積

維持 EOL 之後的版本意味著累積 技術債。當需要升級時，遷移成本會飆升，且過時的相依性會蔓延。

結果是，延遲越久，成本與風險越高。

如何安全運作

為避免 EOL 風險，你不一定需要立即升級——但重要的是 規劃你的遷移。了解目前 MySQL 版本的狀態，考慮距離 EOL 的剩餘時間，並評估遷移目標以準備穩定環境。

下一節將介紹你可以選擇的遷移目標選項，展示它們的功能與建議使用情境。

4. 遷移選項：按目的選擇最佳策略

EOL 處理的關鍵是「遷移策略」

隨著 MySQL 接近 EOL，最重要的決策是 「遷移到哪裡」。僅升級是不夠的；你必須選擇符合系統需求與運營結構的選項。

以下介紹三種主要遷移模式，並說明其特點與目標使用者。

升級至 MySQL 8.0 或 8.4 LTS（保守且以穩定為主）

最簡單的選擇是升級至 較新的 MySQL 版本。目前 MySQL 8.0 是標準，且從 2024 年起焦點轉向 MySQL 8.4 LTS（長期支援版）。

• 優點：
• 與現有 MySQL 環境高度相容
• 仍可作為開源使用
• 既有工具如 MySQL Workbench 仍可使用
• 缺點：
• 某些語法或規格變更可能導致相容性錯誤
• 儲存引擎或字元集可能需要注意
• 最適合：
• SMB 或開發者，想在不進行重大系統變更的情況下維持穩定運營

遷移至替代 RDBMS（MariaDB / TiDB）（彈性與未來保護）

遷移至 MySQL 兼容的 RDBMS 也是一個強有力的選擇。特別受歡迎的是 MariaDB 與 TiDB。

• MariaDB:
• MySQL 的分支，語法與管理方式相似
• 由社群主導的活躍開發
• 擁有豐富的效能優化功能
• TiDB:
• 雲原生分散式 SQL 資料庫
• 適合高可用與可擴充性
• 在分析（OLAP）與交易（OLTP）工作負載上表現優秀
• 最適合:
• 計畫大規模資料處理或雲端遷移的公司
• 想採用尖端開源技術的技術先進團隊

雲端管理資料庫服務（降低運維負擔 & 可擴充）

若想降低本機運維負擔，請考慮使用 雲端管理的關聯式資料庫服務。典型服務包括：

• Amazon RDS for MySQL
• AWS 提供的管理服務
• 內建自動備份與冗餘
• 可自動升級—需謹慎
• Google Cloud SQL for MySQL
• GCP 提供的管理服務
• 高度可擴充並整合其他 GCP 服務
• 使用者友善介面，初學者更易管理
• 優點:
• 無需維護作業系統或硬體
• 不需要深度基礎設施知識
• 缺點:
• 持續的雲端服務費用
• 微調可能較困難
• 最適合:
• 小至中型網頁應用程式運營
• 追求運營效率的創業公司或網路商業

[Comparison Table] 主要選項與功能摘要

接下來的章節將整理實際遷移時的步驟與重點。讓我們檢視實務流程以避免失敗。

5. MySQL 遷移步驟與檢查清單（避免失敗）

遷移即是「80% 的準備」

在 MySQL EOL 遷移中，這不僅僅是版本升級，而是 謹慎流程與充分準備至關重要。尤其在生產環境中，確保資料完整性與服務連續性是首要任務。

我們將所需步驟拆分為 五個階段，並詳細說明。

步驟 1：目前環境調查與清單

首先，您必須蒐集目前系統的 MySQL 版本、設定與相依性。檢查以下項目：

• MySQL 版本與編譯編號
• 使用的字元集（例如 utf8mb4）
• 儲存引擎（InnoDB、MyISAM）
• 使用中的 SQL 語法或函式（可能受版本影響）
• 已連結的應用程式或外部服務

✅ 目標：確保您已辨識所有相依性，以避免遷移後的故障

步驟 2：相容性驗證

檢查目標版本是否 與您目前環境相容。在主要 MySQL 升級時，以下幾點常造成不相容：

• 使用已移除的語法或保留字
• 系統變數或參數不同

🔎 mysql_upgrade 指令或 MySQL Shell Upgrade Checker Utility 可執行相容性診斷。

步驟 3：備份並建立測試環境

直接在生產環境升級風險過高。首先取得 完整備份，再以此建立 測試/暫存環境。

• 使用 mysqldump 或 mysqlpump 轉儲
• 基於檔案的備份（如 XtraBackup）
• 於測試環境還原並執行應用程式測試

在此階段，您可 提前偵測遷移後的缺陷或 SQL 錯誤，從而減少生產遷移時的麻煩。

步驟 4：資料遷移至生產環境

驗證完成後，即可進行生產環境遷移。若可能，建議於 夜間或低流量時段 執行。

• 在生產切換前進行最後備份
• 暫停服務（如可，安裝維護頁面）
• 將資料匯入新版本資料庫
• 調整設定檔與環境變數

另外，應用程式端可能需要更改 MySQL 的連線端點，請特別留意切換時機。

步驟 5：運營驗證與優化

遷移完成後，切換完成並不代表遷移已經完成。
請檢查以下項目以 確認新 MySQL 環境的穩定運作。

• 驗證應用程式的連線
• 檢查 SQL 查詢效能及無錯誤
• 監控日誌檔案（錯誤日誌、慢查詢日誌）
• 透過快取設定或索引重建進行優化

如有必要，執行 ANALYZE TABLE 或 OPTIMIZE TABLE 以 恢復遷移期間下降的效能。

檢查清單（最終審核）

✅ 確認目前版本與設定
✅ 事前診斷相容性
✅ 取得完整備份
✅ 在測試環境進行測試
✅ 規劃並執行正式切換
✅ 監控遷移後的錯誤與效能

成功遷移的關鍵在於「組織準備」。尤其是 EOL 遷移，應以有序的準備、驗證與切換方式進行，而非匆忙。

6. 雲端服務的 EOL 回應（適用於 AWS 與 GCP 使用者）

即使使用雲端 MySQL，也不要自滿

即使在 Amazon RDS 或 Google Cloud SQL 等雲端環境使用 MySQL，EOL（支援結束）問題仍然相關。雲端服務有時會在版本到達 EOL 時實施 「自動升級」或「服務退休」，因此提前規劃非常重要。

以下說明主要雲端服務的 EOL 處理方式。

Amazon RDS for MySQL：注意自動升級

使用 AWS 的托管服務 Amazon RDS for MySQL 時，曾多次發生 強制版本退休及支援結束後的自動升級。

• MySQL 5.5：2018 年結束 → 自動升級至 5.6
• MySQL 5.6：2021 年結束 → 從 2022 年起自動升級至 5.7

這可能導致使用者的 MySQL 版本意外切換，並引發 應用程式錯誤或效能下降。

✅ 對策：自行規劃升級時機

AWS 會透過電子郵件或主控台通知提前告知，但若未及時處理，可能會自動執行升級。

Google Cloud SQL for MySQL：第一代 EOL 與遷移推動

使用 Google Cloud 的托管服務 Cloud SQL for MySQL 時，舊版本與架構的退休已進行。

• 第一代實例已無法再建立
• 針對 EOL 的版本會採取 升級鼓勵政策

雖然 Google 會尊重使用者自由，但仍有 支援延長的時間限制，因此需提前升級或重建。

此外，Cloud SQL 擁有 自動備份與故障轉移 等豐富功能，但 SQL 模式預設或時區差異 可能不易察覺，進而造成問題。

✅ 重要：提前測試雲端特定設定與相容性

雲端優勢與 EOL 回應陷阱

使用雲端服務帶來優勢，但若 EOL 回應薄弱，可能成為問題源頭。

即使在雲端，EOL 回應的責任仍由使用者承擔。

雲端 EOL 回應清單

✅ 確認您使用的 MySQL 版本及其 EOL 時程
✅ 啟用雲端供應商的通知設定（電子郵件、SNS）
✅ 檢查是否會自動升級
✅ 在測試環境測試新版本
✅ 如有需要，規劃應用程式側的任務或調整

為充分利用雲端便利，您不能僅僅「交給雲端」。相反，您需要 內部監督與監控。尤其是 MySQL EOL，即使在雲端環境也需要強固的準備與規劃。

7. 常見問題（FAQ）

Q1：支援結束後，我還能繼續使用 MySQL 版本嗎？

A: 技術上可行，但不建議。

EOL 版本的 MySQL 不會收到安全修補或錯誤修正。因此，利用漏洞的攻擊風險急劇上升，您可能違反法規或安全政策。

即使系統看似正常運作，你仍處於 隱藏的高風險狀態。請考慮提前升級或遷移。

Q2：MySQL 8.0 與 8.4 LTS 有何差異？

A：MySQL 8.4 LTS 是一個更長期支援的穩定版本。
MySQL 8.0 是常規發布週期，預計於 2025 年 4 月失去主力支援。另一方面，MySQL 8.4 LTS（長期支援）提供約五年的延伸支援，作為穩定版本。

如果你重視長期可靠性和企業使用，建議遷移至 MySQL 8.4 LTS。

Q3：遷移成本是多少？

A：成本會因遷移規模與選擇而大相徑庭。
例如，如果你在同一台伺服器內將 MySQL 版本升級，成本可能為 零。然而，遷移至雲端服務或切換至其他產品（MariaDB 或 TiDB）可能會產生 設計、建置、測試工作以及技術支援成本。

停機時間緩解的備份以及測試環境的準備也必須納入成本規劃。

Q4：在遷移生產系統時應注意什麼？

A：預先測試與分階段遷移是關鍵。
在生產環境中，你必須執行 相容性檢查、備份、測試環境測試。同時利用讀取副本或 藍綠部署（在遷移期間同時運行舊環境和新環境） 有助於最小化停機時間。

為安全起見，請在夜間或非高峰時段執行工作。

Q5：我可以在雲端停止自動升級嗎？

A：你可以控制部分設定，但最終仍須遵循供應商政策。
使用 Amazon RDS 或 Cloud SQL，你可以 延遲或避免自動升級排程，但當版本達到 EOL 時，可能會強制升級。

長期避免較困難；因此，使用者規劃升級是最可靠的方法。

Q6：選擇替代資料庫時有什麼標準？

A：是的：根據以下三個軸線做決策。

1. 相容性：目前的應用程式或 SQL 會有多少能直接使用。
2. 可擴充性與未來可行性：它能否處理增加的資料量和流量。
3. 運營能力：你能否自行維護，或需要供應商支援。

尤其在商業系統中，與實際運營能力對齊比跟隨趨勢更重要。

8. 摘要 | 在支援結束前你能做的最佳舉措

EOL 不是「還遠」而是「已經近在咫尺」

MySQL EOL 不僅僅是少數 IT 員工的問題。它影響整個組織的安全、效能、可用性和成本管理。

特別是 MySQL 5.7 已於 2023 年 10 月結束支援，而 8.0 預計於 2025 年 4 月失去主力支援。換句話說，如果你認為「仍在運行就沒問題」，你可能已處於 關鍵風險 狀態。

計畫性遷移是最有效的風險避免措施

正如本文所述，分階段進行遷移並不困難。

• 盤點目前版本
• 檢查相容性並選擇遷移目標
• 在測試環境中測試
• 執行分階段遷移並切換

如果你遵循這些步驟，你可以安全完成遷移，避免服務停止或資料遺失等問題。

即使你使用雲端服務，也不應僅依賴供應商。相反，你必須了解自身情況並積極規劃升級策略。

“不再只是說你不知道”

在現代 IT 運營中，持續的維護意識比單純的技術知識更重要。了解 EOL 資訊、評估風險並選擇最佳遷移目標是所有運營工程師和開發人員必備的技能。

最後：你應該立即採取的三項行動

1. 檢查您的系統使用的 MySQL 版本
2. 確認該版本的 EOL（終止支援）日期並記錄下來
3. 與您的團隊討論是否升級或遷移到其他資料庫

處理 MySQL EOL 就像保險，能防止未來的事故。
使用這篇文章作為催化劑，審視您的安全與可持續運營框架。