不選擇 MySQL 的五大理由：授權模式、成熟度、功能完備度、認證體系與擴展性爭議

理性評估：為什麼企業可能拒絕 MySQL？

技術選型無絕對優劣，只有權衡。本文客觀分析五大可能導致放棄 MySQL 的理由，助決策者全面評估風險。

理由一：雙重授權模式的法律與成本風險

• GPL 传染性： 若應用非開源 (非 GPL 相容)，嵌入 MySQL 庫 (libmysqlclient) 可能觸發 GPL 義務，需開源整個應用
• 商業授權成本： Oracle 官方商業授權 ~$2,000-$5,000/伺服器/年，大規模部署成本可觀
• 替代方案： PostgreSQL (BSD/MIT 授權)、MariaDB (GPL 但有非伝染性客戶端庫)、SQLite (公共領域)
• 風險緩解： 使用非 GPL 驅動 (MariaDB Connector/C、MySQL Connector/J 經過 FOSS License Exception)、或走雲託管服務 (RDS、CloudSQL) 由廠商承擔授權

理由二：產品成熟度與企業級信賴度

• 保守型 IT 經理在「核心帳務、醫療、電信計費」等零容忍場景，傾向選擇驗證更久的平台
• MySQL 5.0 (2005) 前缺乏存儲過程、觸發器、視圖、外鍵 (InnoDB 除外)，企業級功能相對晚成

理由三：關鍵企業級功能的成熟度與完備度

理由四：認證體系與人才標準化程度

• Oracle OCP/OCM： 全球公認、嚴格實作考試、企業招聘硬指標
• Microsoft MCSE： 體系完整、配合產品版本更新
• MySQL 認證： Oracle 提供 OCA/OCP，但認知度、含金量、考試深度遠低於 Oracle 認證
• 企業級專案招標常要求「持有廠商高級認證人員 N 名」，MySQL 難以滿足

理由五：水平擴展架構的爭議與限制

• MySQL 原生： 主從複寫 (非同步/半同步)、Group Replication (單主/多主、< 9 節點)、InnoDB Cluster
• 水平分片： 無原生透明分片，需中間件 (ProxySQL、Vitess、ShardingSphere) 或應用層路由
• 對比：
  • Oracle RAC：共享存儲、多活、透明擴展
  • PostgreSQL：Citus、Patroni、原生邏輯複寫支援雙主
  • NewSQL (TiDB、OceanBase、CockroachDB)：原生分散式 SQL、強一致、彈性擴展
• 大規模擴展場景下，MySQL 運維複雜度指數級上升，團隊需具備深厚內核知識

綜合建議：決策檢查清單

1. 應用授權模式是否相容 GPL？否 → 評估商業授權成本或換 PostgreSQL
2. 是否為零容忍核心業務 (帳務/醫療/電信)？是 → 評估 Oracle/PostgreSQL/NewSQL
3. 是否大量依賴複雜存儲過程、CTE、窗口函數、並行查詢？是 → 評估 PostgreSQL 8.0+ / Oracle
4. 招標是否要求廠商高級認證？是 → 考慮 Oracle/SQL Server
5. 未來 3 年是否需 PB 級水平擴展？是 → 評估 TiDB/OceanBase/Vitess 架構
6. 團隊是否有深厚 MySQL 內核運維能力？否 → 選擇託管服務 (RDS/CloudSQL) 或換平台

「不選 MySQL」不代表 MySQL 不好，而是「當下語境下有更適合的選擇」。技術決策應基於業務約束、團隊能力、長期演進三維度綜合判斷，而非單一維度偏好。

1. 上一篇文章： 選擇 MySQL 的五大核心理由：普及度、簡單性、低成本、支援與彈性
2. 下一篇文章： ODBC 連接 MySQL 實戰：Windows 環境驅動安裝與系統 DSN 配置

MySQL 綜合教學

MySQL 性能調優與架構設計第 14 章：數據切分 (Sharding) 垂直/水平/混合架構與中間層整合方案

從單機到叢集：MySQL 數據切分 (Sharding) 完

Windows 下 MySQL 反覆安裝失敗：殘留 data 目錄導致配置不覆蓋的終極解法

現象 卸載重裝 N 遍仍報錯/無法初始化 刪註冊表無效

解決 MySQL 無法解析主機名稱錯誤 (#1042) 的完整指南

錯誤現象 當嘗試連線 MySQL 伺服器時，可能會遇到以下錯

MySQL開發團隊穩定留任Oracle，核心引擎開發未受影響

隨著Oracle完成對Sun Microsystems的收購