文獻背景
- 作者：Ben Adida，譯者：馬維達
- 時間：2000 年 5 月 (MySQL 3.23 早期，無 InnoDB、無事務、無外鍵)
- 目的：回應社區「為何 OpenACS 不用 MySQL」的高頻提問
- 價值：**歷史鏡像**，見證 MySQL 從「玩具」到「企業級」的演進，理解 ACID 在架構選型中的核心地位
核心論點：MySQL 違背 ACID 原則
Atomicity (原子性) 缺失
無事務支援：UPDATE ...; INSERT ... 兩條語句中間斷電/崩潰，**部分生效、部分回滾不可控**。Oracle/PostgreSQL 保證「要麼全成、要麼全不成」。
Consistency (一致性) 缺失
- 無外鍵約束：無法在數據庫層強制
forum.posts.user_id REFERENCES users(id)
- 無 CHECK 約束：無法限制
age > 0 AND age < 150
- 應用層邏輯極易出 Bug，數據庫成「垃圾場」
Isolation (隔離性) 缺失
表級鎖 (MyISAM)：**寫鎖阻塞所有讀/寫**，併發性極差。無 MVCC，讀寫互斥，長事務鎖死全表。
Durability (持久性) 風險
- 無 WAL (Write-Ahead Logging) / Redo Log
- 崩潰後數據文件極易損壞，需
myisamchk 修復，**修復過程可能丟數據**
- 無雙寫緩衝、無校驗和
補充缺陷
| 缺陷 | 影響 | 後續解決版本 |
|---|
| 無子查詢 | 複雜邏輯需應用層多次查詢/臨時表 | 4.1 (2004) |
| 無存儲過程/觸發器/視圖 | 業務邏輯無法下沉、遷移困難 | 5.0 (2005) |
| 無準備語句 | SQL 注入風險高、解析重複開銷 | 4.1 (2004) |
| 字符集支援極弱 | 多語言應用極難 | 4.1 (2004) |
| 單線程/表鎖架構 | 多核利用率低、寫入擴展性差 | 5.1 行鎖/插件架構、5.6+ 並行查詢 |
歷史還原：MySQL 如何逐步補齊？
- 3.23.34+ (2001)：引入 **InnoDB** (第三方引擎)，提供事務、行鎖、外鍵、崩潰恢複 → **ACID 拼圖關鍵一塊**
- 4.0 (2003)：查詢緩存、複製、InnoDB 內建
- 4.1 (2004)：子查詢、準備語句、字符集、幫助系統
- 5.0 (2005)：存儲過程、觸發器、視圖、游標、INFORMATION_SCHEMA
- 5.1 (2008)：分區表、事件調度器、插件式存儲引擎、Row-based 複製
- 5.5 (2010)：InnoDB 成為默認引擎、**徹底終結 MyISAM 時代**
- 5.6/5.7 (2013/2015)：GTID、並行複製、全文索引、JSON、Sys Schema、性能結構
- 8.0 (2018)：CTE、窗口函數、降序索引、隱式索引、資源組、數據字典原子化、Clone Plugin、Redo Log 並行
批判的局限性與歷史公允性
- **針對 2000 年 MySQL 3.23 (MyISAM) 完全準確**，若用於核心交易/金融/ERP 確屬不當
- **忽略了「場景適配性」**：讀多寫少、非關鍵、原型驗證、嵌入式、日誌分析等場景 MyISAM 極具性價比
- **低估了開源迭代速度**：社區 + 商業雙驅動，4 年解決核心 ACID 缺失，8 年成企業級標配
- **未提 PostgreSQL 同期狀態**：2000 年 PG 7.0 剛有外鍵/事務，但安裝複雜、Windows 不支援、文檔匱乏，MySQL「易用」贏得市場
現代選型啟示
- ACID 非可選項**：核心交易、金融、庫存、訂單，**必須**事務型引擎 (InnoDB/PostgreSQL/Oracle/SQL Server)
- 存儲引擎可見性**：
SHOW ENGINES; 確認 InnoDB DEFAULT，嚴禁生產用 MyISAM/Memory 存核心數據
- 遷移兼容性**：舊應用遷移新版，必測 SQL_MODE、保留字、優化器行為、字符集
- 歷史包袱清理**：定期掃描
ENGINE=MyISAM 表，遷移或歸檔
結語
這篇 2000 年的批判，在當時是**技術負債預警**，放在今天是**演進史教材**。MySQL 用 20 年證明：**開源項目敢於直面缺陷、快速迭代補齊、社區商業共振，終能從「不配」走向「標配」**。但對架構師而言，**「不選 MySQL」的理由在 2000 年成立，在 2024 年同樣成立——若你的業務需要 ACID，卻還在用非事務引擎、無備份、無監控、無演練的 MySQL，那才是真正的不專業。**
