前言：兩大開源資料庫的百年恩怨
MySQL (Oracle) 與 PostgreSQL (社群驅動) 代表了商業化開源 vs 純社群開源、效能優先 vs 功能完整、線程模型 vs 進程模型兩種截然不同的基因。本文基於 MySQL 4.0.2-alpha (首支援事務) 與 PostgreSQL 7.2 歷史版本對比，並補充現代版本 (8.0 vs 15+) 演進視角，提供跨時代選型參考。
一、共同優勢：開源雙雄
- 源碼透明、無廠商鎖定、社群龐大、文檔豐富、生態成熟。
- 商業級任務關鍵系統均有大規模落地案例 (Facebook/Google/Ubuntu vs Apple/Instagram/Skype)。
二、基因差異：公司 vs 社群
| 維度 | MySQL | PostgreSQL |
|---|
| 背後實體 | MySQL AB → Sun → Oracle (商業公司) | PostgreSQL Global Development Group (鬆散社群) |
| 發布節奏 | 較謹慎、版本週期長、穩定性優先 | 較激進、功能快速迭代、社群駕馭 |
| 商業支援 | 官方 Enterprise、第三方豐富 (Percona, MariaDB) | 第三方為主 (EDB, 2ndQuadrant, Citus Data) |
| 授權模式 | GPL + 商業雙授權 (Oracle 擁有) | PostgreSQL License (類 BSD/MLT, 極度寬鬆) |
三、MySQL 核心優勢 (歷史 + 現代)
- 讀寫效能極致：線程模型、查詢快取 (舊版)、InnoDB 自適應雜湊索引、讀多寫少場景冠軍。
- Windows 原生支援：原生服務、無需 Cygwin、GUI 工具鏈豐富 (Workbench, Navicat)。
- 複寫生態成熟：主從、半同步、Group Replication、InnoDB Cluster、一鍵部署。
- 連線處理輕量：單進程多線程，單連線記憶體 ~256KB vs PostgreSQL ~10MB。
- 無需 VACUUM：MVCC 清理由背景線程自動完成，7×24 無維護窗口。
- 權限系統細粒度：欄位級、主機級、Proxy 用戶、角色 (8.0+)。
- 引擎可插拔：InnoDB/MyISAM/MEMORY/CSV/Archive/NDB/Spider... 適配多樣負載。
- 事務引擎可選：同一實例混用事務/非事務表，靈活權衡。
四、PostgreSQL 核心優勢 (歷史 + 現代)
- 功能完整度標桿：存儲過程 (PL/pgSQL, PL/Python, PL/Perl...)、觸發器、視圖 (物化視圖)、外鍵、檢查約束、排除約束、域類型、繼承、分區 (10+)、邏輯複寫、並行查詢、JIT 編譯。
- ACID 鐵律：事務隔離級別完整支援 (含 Serializable SSI)、無「讀取未提交」殘留。
- 進程隔離安全：單進程崩潰不影響其他連線，記憶體保護更強。
- 擴展性極強：Extension 機制 (PostGIS, TimescaleDB, Citus, pg_stat_statements, pgvector, zhparser...) 生態豐富。
- 複雜查詢優化器：GEQO (遺傳演算法)、並行執行、Hash Join、Merge Join、Partition Pruning、Partition-wise Join。
- 全文搜尋內建：tsvector/tsquery、多語言分詞、排序規則、排名函數。
- 地理空間原生：PostGIS 黃金搭檔，R-Tree/GiST/SP-GiST 索引。
- JSON/JSONB 完整支援：索引 (GIN)、運算子、路徑查詢、生成欄位。
五、現代版本關鍵差距收斂表 (MySQL 8.0 vs PostgreSQL 15)
| 特性 | MySQL 8.0 | PostgreSQL 15 | 備註 |
|---|
| CTE / 遞歸查詢 | 支援 | 支援 | 已對齊 |
| 窗口函數 | 支援 | 支援 | 已對齊 |
| JSON/JSONB | JSON (功能較弱) | JSONB (功能強、可索引) | PG 勝出 |
| 並行查詢 | 有限支援 | 成熟並行 (Parallel Seq Scan, Hash Join) | PG 勝出 |
| 邏輯複寫 | 支援 | 支援 (發布/訂閱) | 已對齊 |
| 分區表 | Range/List/Hash/Key | Range/List/Hash + Partition Pruning | PG 更強 |
| 全文搜尋 | ngram parser (中文弱) | tsvector + zhparser/jieba (中文強) | PG 勝出 |
| 地理空間 | 基礎 GIS | PostGIS 專業級 | PG 完勝 |
| 存儲過程 | 支援 (功能受限) | PL/pgSQL + 多語言 (功能極強) | PG 完勝 |
| 連線池 | ProxySQL (外掛) | PgBouncer (標準) | 各有優勢 |
| 監控生態 | PMM, Grafana | pg_stat_statements, pgBadger, Grafana | 各有優勢 |
六、選型決策樹 (2024 版)
- 作業系統強制 Windows？→ MySQL (PG Windows 仍非一等公民)。
- 團隊無資料庫深度經驗、需快速上手？→ MySQL (文檔、工具、人才供給最豐富)。
- 純讀多寫少、極致讀效能、簡單 CRUD？→ MySQL。
- 核心業務、強一致性、複雜事務、豐富約束？→ PostgreSQL。
- 需存儲過程封裝業務邏輯、減少網路往返？→ PostgreSQL。
- 地理空間、時間序列、向量搜尋、圖計算？→ PostgreSQL + Extension。
- 中文全文搜尋核心需求？→ PostgreSQL + zhparser。
- 團隊熱愛內核開發、想貢獻/定製引擎？→ PostgreSQL (社群歡迎貢獻者)。
- 既有 MySQL 生態、遷移成本極高？→ 留在 MySQL，優化現有架構。
七、避坑指南：別被歷史刻板印象誤導
- 「MySQL 不支援事務」：5.0+ InnoDB 預設事務引擎，8.0 更強。
- 「PostgreSQL 效能差」：並行查詢、JIT、分區剪枝，OLAP 負載常超越 MySQL。
- 「MySQL 易遺失資料」：
innodb_flush_log_at_trx_commit=1 + 雙 1 同步複寫 = 0 資料遺失。
- 「PostgreSQL 維護麻煩」：Autovacuum 已高度智能化，13+ 幾乎零干預。
結語
MySQL 與 PostgreSQL 已進化為各自領域的冠軍，而非單一優劣關係。選型本質是業務負載特徵 × 團隊能力矩陣 × 生態鎖定成本的多目標優化。建議：核心交易系統雙積候選、POC 實測、以數據說話。無論選擇哪一款，深度掌握其優化精髓、建立標準化運維體系，才是決定成敗的關鍵。
