戰略定位轉折
MySQL 明確不再追求替代 Oracle/DB2 等傳統企業級非共享架構數據庫，而是專注 Web 2.0 / 企業 2.0 應用的核心數據庫。隨著用戶規模、數據量、交易量指數級增長，可擴展性成為核心競爭力。
核心技術投入方向
1. Sun 協同深度性能調優
- 收購後，MySQL 產品副總裁 Zack Urlocker 領導團隊與 Sun 性能工程師緊密合作。
- 利用 Sun DTrace 動態追蹤技術，在生產級負載下進行微觀級性能分析，定位 Server 層與存儲引擎層瓶頸。
- 開展極端條件壓力測試，優化鎖競爭、內存分配、I/O 路徑，提升多核擴展性。
2. Memcache 深度整合：緩存層下沉與架構融合
- 雙方收購前均獨立投入 Memcache 研發：高性能分布式緩存，大幅卸載 DB 讀壓力，通過全局緩存將熱點數據分散至低成本緩存節點。
- 整合目標：
- 查詢緩存增強：MySQL 內置 Query Cache 存在鎖競爭、失效率高等缺陷，Memcache 可作為分布式二級緩存補位。
- 寫入緩衝：異步寫入模式下，Memcache 吸收突發寫入，批量回寫 DB。
- 會話/中間狀態存儲：Web 應用會話數據、購物車、Token 直接落 Memcache，減少 DB 連接。
- 技術路線：Connector/J、Connector/NET、PHP 驅動層面原生支持 Memcache 協議；存儲引擎層探索
ndb_api 直連 Memcache 節點。
3. 存儲引擎多樣化：針對性解決擴展痛點
| 引擎 | 擴展維度 | 典型場景 |
|---|
| InnoDB / XtraDB | 事務一致性、行鎖並發、崩潰恢復 | 核心交易、用戶中心、訂單系統 |
| MyISAM / Archive | 唯讀高壓縮、全掃描吞吐 | 日誌歸檔、報表數據集市 |
| NDB Cluster | 分布式內存、跨機房強一致、自動分片 | 電信級計費、實時競價、高可用會話 |
| Falcon (已廢) | 多核優化 MVCC、壓縮頁面 | 歷史嘗試，最終被 InnoDB 迭代吸收 |
| Maria / PBXT | 崩潰安全 MyISAM 替代、寫入優化 | MariaDB 內置選項 |
市場機會窗口：Web 2.0 爆發期
- 451 Group 分析師 Matt Aslett 指出：企業對開源數據庫應用「廣泛但膚淺」，多為避免專有軟件許可成本而部署邊緣項目。
- MySQL 策略轉向：不在傳統 OLTP/數據倉庫領域正面硬剛 Oracle，而是深耕 Web 應用開發者需求——彈性擴展、部署簡單、運維低成本、語言生態友好。
- 預判：未來十年增長極在於 Web 2.0 最佳實踐沉澱（分庫分表、讀寫分離、緩存分層、異步隊列、最終一致性模式）。
數據倉庫新戰場與列式引擎前瞻
- Urlocker 透露：數據倉庫領域對開源仍是「處女地」，2008 年將見證基於 MySQL 頂層架構的專用列式存儲引擎登場（如 Infobright、Calpont InfiniDB、後續 MariaDB ColumnStore、ClickHouse 前身）。
- 列式引擎特徵：列存儲、向量化執行、高壓縮比、適配 OLAP 大寬表掃描聚合，與行式 InnoDB 形成 HTAP 混合負載能力。
歷史回顧與啟示
- 戰略聚焦勝於全面鋪開：MySQL 放棄企業級核心 OLTP 戰場，專注 Web 規模化擴展，贏得了 Facebook、Twitter、YouTube、淘寶等超大規模用戶案例，反哺內核迭代。
- 開源生態韌性：Sun/Oracle 收購引發核心團隊流失，但 Monty 創建 MariaDB、Percona 深耕性能、Drizzle 探索微內核，開源力量確保技術血脈傳承。
- 緩存即架構：Memcache 整合預示了現代「緩存旁路/寫穿/讀穿」模式，以及 Redis 作為數據結構服務器的崛起。
- HTAP 趨勢雛形：列式引擎嘗試預示了 TiDB、PolarDB HTAP、MySQL 8.0+ 列式索引等混合負載方向。
