前言
MySQL 經歷 Sun（2008）與 Oracle（2009）兩次收購後，核心開發團隊大量流失，催生了豐富的存儲引擎創新與數據庫分支生態。本文系統梳理主流引擎之外的關鍵引擎（Falcon、SolidDB、XtraDB、Maria、PBXT）與主流分支，為技術選型提供歷史脈絡與現狀參考。
一、核心存儲引擎補充：InnoDB 替代者的探索
1. Falcon —— 夭折的野心之作
- 背景：Oracle 2005 年收購 InnoBase 後，MySQL AB 急需自主事務引擎。2006 年收購 Netfrastructure，由 Jim Starkey 主導開發，目標嵌入 MySQL 6.0 替代 InnoDB。
- 特性：MVCC、ACID、B+樹前綴壓縮、頁面壓縮（磁盤壓縮/內存解壓）、Group Commit、面向多核大內存優化。
- 現狀：2008 年 Jim Starkey 離職創業 NimbusDB，Falcon 失去核心維護者。Beta 階段性能極差（寫入僅為 MyISAM 1/10~1/20，索引優化缺失），最終被 MySQL 6.0 棄用，隨 MySQL 6.0 專案一同終結。
- 教訓：核心基礎設施依賴單一大師風險極大；架構創新需長期迭代驗證，無法速成。
2. SolidDB —— 被 IBM 收購的企業級引擎
- 特性：基於 MVCC，同時支援悲觀/樂觀並發控制（業內罕見）、完整外鍵、聚簇索引、零開銷在線備份。
- 命運：2008 年被 IBM 收購，併入 IBM 數據庫套件作為前端緩存層，閉源商業化，不再融入 MySQL 社區版。雖性能優異，但對 MySQL 用戶已不可用。
3. XtraDB —— Percona 打造的 InnoDB 增強版
- 定位：100% 兼容 InnoDB，作為「直接替換」存在。Percona 基於 InnoDB 源碼優化 I/O、鎖、內存管理、線程並發。
- 優勢：高併發讀寫性能顯著優於官方 InnoDB（特別是多核場景），穩定性經大規模生產驗證。
- 生態：Percona Server、MariaDB 默認內置 XtraDB；配套工具 XtraBackup（熱備份神器）廣受好評。核心團隊活躍，版本跟進緊貼 MySQL 官方釋出。
- 建議：生產環境強烈推薦替換官方 InnoDB，遷移零代碼修改。
4. Maria —— Monty 回歸打造的下一代 MyISAM
- 作者：MySQL 創始人 Michael "Monty" Widenius，命名自其女兒 Maria。
- 目標：解決 MyISAM 崩潰損壞、無事務、表鎖並發差三大痛點；長遠目標實現全 ACID、MVCC、行鎖、Group Commit，最終替代 MyISAM 成為默認引擎。
- 現狀：MariaDB 5.1/5.5 內置，提供崩潰安全的 MyISAM 替代品（表鎖但讀寫不阻塞），事務特性仍在演進中。
- 特色：增量備份友好（複製日誌即可）、磁盤存儲高效、讀寫並發優於 MyISAM。
5. PBXT (PrimeBase XT) —— 獨特「寫一次」架構的事務引擎
- 創新：避免雙寫（Doublewrite Buffer），通過事務日誌與數據文件協同實現「Write Once」，大幅降低提交開銷，提升寫並發。
- 特性：MVCC、ACID、行鎖、死鎖檢測、外鍵、BLOB 流式存儲（配合 Blob Streaming Engine）、非聚簇索引設計。
- 現狀：MariaDB 內置，性能與 InnoDB 接近且寫入更穩定。社區活躍度一般，但架構思路對後續引擎（如 MyRocks）有啟發。
二、主流 MySQL 分支對比
| 分支 | 核心定位 | 默認引擎 | 關鍵特性 | 成熟度/推薦場景 |
|---|
| MariaDB |
MySQL 直接替代品，兼容性優先 |
XtraDB (InnoDB 兼容)、Maria、PBXT、FederatedX |
線程池、列式存儲、動態列、Oracle 兼容模式、GTID 增強、開源數據庫聯盟核心成員 |
高。生產環境廣泛使用（維基百科、騰訊、阿里等），版本與 MySQL 同步（10.x 對應 5.7/8.0），無縫遷移。 |
| Drizzle |
雲原生、微內核、極簡 MySQL |
InnoDB |
移除存儲過程/視圖/觸發器/查詢緩存/PREPARE；插件化架構、Sharding 內建、無 ACL（依賴 LDAP/PAM）、POSIX 合規、無 Windows 支持 |
中低。適合新建雲原生微服務、大規模分片集群；不適合依賴存儲過程/觸發器的傳統應用遷移。開發活躍度已下降，部分特性被 MySQL 8.0/MariaDB 吸收。 |
| Percona Server |
MySQL 性能增強版 |
XtraDB |
響應時間統計、慢查詢增強、InnoDB 監控表、XtraBackup 集成、數據字典保護 |
高。不改變 SQL 行為，專注性能與可觀測性，適合不想換分支只想榨乾性能的團隊。 |
三、技術選型建議（2024 視角）
- 穩健升級：現有 MySQL 5.6/5.7 → MariaDB 10.6/10.11 LTS 或 Percona Server 8.0，業務代碼零修改，獲得更好並發與工具鏈。
- 新架構選型：雲原生微服務、分片中間件（ShardingSphere、Vitess）場景可評估 TiDB（NewSQL）、PolarDB 等分布式方案；單機極致性能可嘗試 MyRocks（RocksDB 引擎）應對寫入密集負載。
- 避坑指南：Falcon、SolidDB、MySQL 6.0 已成歷史；Drizzle 活躍度低，勿用於關鍵業務；Maria 引擎事務特性尚未成熟，僅作崩潰安全 MyISAM 替代使用。
- 開源韌性：Monty 發起 Open Database Alliance、創建 MariaDB；Percona 深耕性能工程；社區力量確保 MySQL 基因在 Oracle 掌控下仍持續進化。
四、NoSQL 浪潮下的定位
Key-Value（Redis）、文檔、寬表（HBase/Cassandra）在特定場景替代關係型 DB，但 ACID 事務、複雜關聯查詢、成熟生態仍是 MySQL/MariaDB/PostgreSQL 核心優勢。未來 5-10 年，關係型與多模數據庫共存將是常態，選型核心在於「業務場景匹配度」而非單純技術新舊。
