MySQL vs PostgreSQL 實戰性能大比拼：SourceForge 架構選型紀實

「選 MySQL 還是 PostgreSQL？」這個困擾開發者多年的問題，作者通過 SourceForge 早期架構選型中的真實壓測數據，給出了極具參考價值的答案。

測試背景與數據環境

• 時間：1999 年 9 月，SourceForge 基礎設施建設初期
• 測試頁面：討論區頁面（3 表關聯、2-3 萬行數據、遞歸嵌套結構）
• 硬件：VA Linux 四路 Xeon 4100 服務器，1GB RAM，Red Hat Linux 6.2
• 版本：MySQL 3.22.30 vs PostgreSQL 7.0.2
• 工具：ApacheBench (ab) 並發壓測，100M LAN 環境

PostgreSQL 遇到的關鍵阻礙

1. 8KB 行大小限制：導入論壇數據時因超過 8KB/行阻塞，被迫丟棄 body 字段繼續測試（7.1 版本修復，但重編譯支持 32KB 會損害整體性能）
2. Serial 類型序列殘留問題：刪除父表時序列不自動清理，重建表導致名稱衝突，新手易踩坑
3. 導入數據時序列不重置：與 MySQL auto_increment 自動遞增形成鮮明對比

測試方法論

• 實際生產頁面代碼，僅將 mysql_query() 替換為 pg_exec()
• 包含大量 SELECT/JOIN 操作，模擬真實網站負載
• 腳本注入 10% 隨機 INSERT 操作（模擬發帖比例）
• 使用真實生產數據集，最大程度還原實際場景

核心性能數據對比

關鍵發現：MySQL 在中低並發下吞吐率碾壓 PostgreSQL（~1.5-1.6 倍），但 90+ 並發時因連接管理機制崩潰；PostgreSQL 雖單請求慢，但高並發下極其穩定，無崩潰記錄。

選型決策與啟示

SourceForge 最終選擇 MySQL，主要基於：

• 當時業務並發壓力在 MySQL 穩定範圍內
• MySQL 部署維護更簡單，團隊熟悉度高
• PostgreSQL 7.0 的行大小限制與序列問題對業務衝擊大

現代視角補充：當前 PostgreSQL 14+ 與 MySQL 8.0+ 均已解決歷史短板，選型應基於具體業務場景（如複雜查詢/事務/JSON 支持等）而非歷史刻板印象。

1. 上一篇文章： Windows 98 + PWS 環境下 ASP 連接 MySQL 實戰教程
2. 下一篇文章： MySQL 從表中高效提取隨機數據的兩種方案對比

MySQL 資料庫相關知識

解決 SQL Server 2005 ODBC 連線錯誤 18452 的完整步驟

在使用 .NET 開發的網站連接 SQL Server 20

Windows 7 部署 MySQL 5.6 解壓版完全指南：解壓、環境變量、配置文件、服務安裝與啟動故障排查

前言：Windows 下的「綠色部署」藝術 MySQL 5.

解決 MySQL 5.7 插入中文顯示問號（?）或報錯 Incorrect string value 的字符集配置指南

問題現象 插入中文報錯：Incorrect string

NaviCat 連接遠程 MySQL 「不支援遠程連接」解決方案：HTTP 隧道通道完整配置圖解

適用場景 虛擬主機/共享主機禁止 3306 直接連線 僅開