MySQL 在大型企業關鍵業務中的挑戰與現狀
雖然 MySQL 有越來越多成功部署案例，但大企業核心系統仍多觀望。本文從儲存引擎、線上 DDL、備份、儲存層、商業支援五維度分析。
1. 儲存引擎困境
- MySQL 缺乏自有成熟事務引擎，InnoDB 最可靠但掌握在 Oracle 手中。
- Falcon 開發兩年進展有限，核心開發者 Jim Starkey 已離職。
- Sun 收購後短期難自研企業級引擎，除非從 Oracle 買回 InnoDB。
- 企業級應用實質只能選 InnoDB，但其熱備份工具收費；MyISAM 並發能力不足，不適合高併發寫入。
2. 線上 DDL 鎖表問題
- MySQL 線上 DDL (加欄位、建索引等) 需鎖表，高可用+頻繁變更環境極痛苦。
- PostgreSQL 支援
CREATE INDEX CONCURRENTLY 減輕影響。
- MySQL 後續版本引入
ONLINE 關鍵字逐步改善，但仍是痛點。
- 暫時對策：預留足夠空閒欄位減少結構變更。
3. 線上備份能力
- MySQL 6.0 才具備原生線上備份，主流仍在 5.x。
- 資深用戶通常自建備份策略 (如 LVM 快照、xtrabackup)，但可能缺乏時間點恢復 (PITR) 能力。
4. 分區與 Sharding
- MySQL 現已支援分區，但推出較晚。
- 大多數用戶採用應用層 Sharding 切分資料，分區非關鍵需求。
5. 儲存層解決方案
- 少人在 MySQL 用 Raw Device，多直接放檔案系統，可靠性存疑。
- 缺乏類似 Oracle ASM 的儲存管理方案。單節點檔案系統限制擴展性 (數 TB 檔案系統故障風險高)。
- LVM2 或 SAN 為可選方案，但儲存廠商對 MySQL 重視度遠低於 Oracle/DB2。
6. 固態硬盤 (SSD) 應用前景
- 企業尋求 IOPS 突破，SSD 為潛力選項。
- 目前缺乏足夠數據證明 MySQL + SSD 能達到數量級 IOPS 提升。
7. 商業支援鏈條風險
- Sun 雖提供商業支援，但核心引擎 InnoDB 在 Oracle 手中，跨廠商協作易產生推諉。
- 未購買服務時，難尋正規整合商支援。
系列預告： 下篇將續論鎖粒度、事務隔離級別、儲存層方案細節。
