2010 年前後，Twitter、Digg、Reddit 等 Web 2.0 巨頭高調宣佈從 MySQL 遷移至 Cassandra 等 NoSQL 方案，引發「關係型資料庫已死」論調。前 Google 工程師 Ted Dziuba 撰文《I Can't Wait for NoSQL to DIE》潑冷水，引發社群激烈辯論。十多年過去，這場辯論的結論早已明朗：**NoSQL 未取代 SQL，雙方形成互補共存生態。**
| 維度 | NoSQL 支持者觀點 | SQL 陣營觀點 (Dziuba / Zawodny / Day) |
|---|---|---|
| 適用規模 | Google 級超大規模、寫入密集、結構變動頻繁 | 99% 企業非 Google 規模，過早優化 = 商業風險 | 運維複雜度 | Schema-less 彈性開發、水平擴展原生支援 | Cassandra 修改 Column Family 需重啟、缺乏成熟工具、一致性調校難 |
| 關鍵業務 | 適合 Feed、Log、Session 等可容忍最終一致性場景 | Google AdWords 核心營收系統仍跑 MySQL (InnoDB/XtraDB) |
| 生態成熟度 | 節省 DBA 成本、開發友善 | ACID、成熟工具鏈、豐富人才池、MySQL 持續進化 (Drizzle, XtraDB, PBXT) |
→ 事實：正確架構下 (讀寫分離、分庫分表、查詢優化、InnoDB Buffer Pool 調校)，MySQL 單機輕鬆支撐萬級 QPS。Memcached/Redis 是加速層，非救命稻草。
→ 事實：Schema 只是隱性搬遷到應用程式碼 (讀取時驗證/轉換)，技術債務轉移而非消失**。NoSQL 遷移 Schema 往往比 ALTER TABLE 更痛苦 (需雙寫、回填、版本相容)。
→ 事實：MySQL/PostgreSQL 透過 Proxy (Vitess, ProxySQL)、中間件 (ShardingSphere)、原生分區表、邏輯複寫均可實現水平擴展。只是操作複雜度較高，需權衡 ROI。
NoSQL **沒有死**，也**不會取代 SQL**。它佔據了「高擴展、弱一致、結構流動」的生態位。關係型資料庫憑藉 ACID、成熟生態、標準 SQL、豐富人才，穩坐「核心業務、強一致、複雜查詢」王座。**最好的架構不是選邊站，而是根據資料特性、業務 SLA、團隊能力、成本預算，在多模型工具箱中挑選最合適的工具組合。**
