在維護企業級或個人專案的資料庫時，選擇一個穩定、支援週期長的 LTS（長期支援） 版本是至關重要的決定。隨著 MariaDB 官方近年架構更動頻繁，許多仍停留在經典版本（如 10.11 LTS）的維運人員，正面臨是否該升級、該跳到哪一個世代的交叉路口。
本文將為你梳理目前主流的 MariaDB LTS 版本特點，並深度解析跨代升級（10 LTS 升級到 11 或 12 LTS）的潛在風險與安全路徑，幫你的資料庫無痛續命！
📌 一張表看懂現行 MariaDB LTS 版本現況
MariaDB 官方針對生產環境提供了不同的長期支援版本。以下是目前市面上最主要的四大 LTS 選擇：
- MariaDB 10.11 LTS (經典穩健)：廣泛使用的舊世代穩定版本，支援至 2028 年 2 月。
- MariaDB 11.4 LTS (目前主力推薦)：穩定可靠的長期維護版本，也是目前的黃金升級目標，支援至 2029 年 5 月。
- MariaDB 11.8 LTS (過渡型 LTS)：包含向量搜尋與複製效能增強的年度 LTS 版本，支援至 2028 年 6 月。
- MariaDB 12.3 LTS (最新世代)：最新推出的長期支援版本，提供優化的向量搜尋與極佳的寫入效能。
🛑 大跨代升級：從 10 LTS 直升 12 LTS 有哪些風險？
如果你的資料庫目前處於 10.11 LTS，想要一步到位直接升級到 12.3 LTS，官方非常不建議這樣做，因為這屬於跨越兩個大版本的重大變更，具備相當高的風險！
直接跨代硬幹，最容易遇到以下三大核心問題：
- 隔離級別預設值變更（Behavior Change）
在 12.3 LTS 中，innodb_snapshot_isolation的預設值改成了 ON（旨在讓REPEATABLE READ的行為更精確）。這可能會改變你既有應用程式的交易（Transaction）鎖定行為，必須實測確認。 - 查詢優化器（Optimizer）行為劇變
11.x 世代對優化器进行了大量重構，全面調整了成本估算模型。部分在舊版 10.x 跑得很快的複雜 SQL 語法，在 12.x 可能因為成本估算模型改變而突然變慢，產生效能退化（Regressions）。 - 廢棄參數與套件依賴衝突
10.11 的許多舊my.cnf參數在 12.x 已被移除，直接沿用可能導致資料庫無法啟動。另外，若有使用 Galera Cluster，12.3 起已移除自動依賴，必須手動補裝mariadb-server-galera，否則叢集會直接無法同步。
⚠️ 官方推薦的安全路徑：必須採兩階段升級。先從 10.11 LTS 升級至 11.4 LTS 並執行結構更新，確認穩定後，再從 11.4 LTS 升級至 12.3 LTS。
💡 折衷方案：如果只升級到 11.4 LTS 呢？
相較於直奔 12 LTS，選擇升級到 11.4 LTS 是目前風險顯著降低、且最為穩健的策略。
從 10.11 到 11.4 是一條官方標準支援的直升路徑，不需要多階段過渡。不過，11.4 畢竟也是重大升級（Major Upgrade），你仍需留意以下轉變：
- 優化器成本模型調整：雖然 11.x 的新優化器對大部分查詢都有利，但極少數複雜的
JOIN或特定索引查詢仍可能誤判。 - 徹底移除 InnoDB Change Buffer：為了簡化代碼並提升現代 SSD 的寫入穩定性，11.0 起已移除此快取。如果應用程式有極大量的「隨機非聚集索引寫入」，可能會觀察到磁碟 I/O 壓力些微上升。
- 一樣不可逆向降級：11.4 使用了全新的 InnoDB 檔案格式與 Redo Log 架構。一旦升級並更新系統表，資料檔案將永久無法退回 10.11 讀取。
📊 升級終極對決：11.4 LTS vs 12.3 LTS
| 評估維度 | 升級至 11.4 LTS | 升級至 12.3 LTS |
|---|---|---|
| 路徑複雜度 | 🟢 低（可直接從 10.11 覆蓋升級） | 🔴 高（需先過渡到 11.4，進行兩次升級） |
| 隔離級別行為 | 🟢 無變更（維持既有鎖定邏輯） | 🟡 有變更（innodb_snapshot_isolation 預設開啟） |
| Galera 套件結構 | 🟢 維持原樣 | 🟡 結構拆分（需手動補裝 Galera 套件） |
| 生產環境建議度 | ⭐ 極高（目前最推薦的穩定長效版本） | 🔵 中（適合需要最新向量搜尋特性的團隊） |
🛠️ 維運人員的「防踩雷」升級準備
不論你最後決定升級到 11.4 還是 12.3，在動手更新 production 環境前，請務必嚴格執行以下三件事：
- 乾淨關閉（Clean Shutdown）：升級前關閉服務時，務必確認
innodb_fast_shutdown不可設定為 2（不可強制崩潰關閉），以確保 Redo Log 完全清空、資料全面落盤，否則新版二進位檔案可能無法讀取舊日誌。 - 完整的物理與邏輯備份：升級失敗是無法直接降級的！請務必使用 MariaDB Backup 進行完整物理備份，並針對
mysql系統資料庫進行mariadb-dump備份。 - 搭建 Staging 環境盲測：強烈建議匯入一份真實資料到測試機，模擬升級流程，並將後端應用的壓測腳本導過去跑一次，觀察有沒有噴任何 SQL 語法錯誤或效能嚴重下滑的現象。
結語
如果你的專案沒有迫切需要 12.x 的新功能（例如最新版的向量搜尋優化），現階段將舊環境升級到 11.4 LTS 是投資報酬率最高、也最安全的選擇。它不僅能避開 12.x 許多行為改變的風險，還能穩定地將你的資料庫安全生命週期一口氣延長到 2029 年。
0 意見:
張貼留言