日韩欧美国产精品免费一二-日韩欧美国产精品亚洲二区-日韩欧美国产精品专区-日韩欧美国产另-日韩欧美国产免费看-日韩欧美国产免费看清风阁

本內容是對知名性能評測博主 Anton Putra MySQL vs PostgreSQL Performance Benchmark (Latency - Throughput - Saturation)^[1] 內容的翻譯與整理, 有適當刪減, 相關指標和結論以原作為準

MySQL vs PostgreSQL 數據庫性能對比

在本內容中，我們將對比 MySQL 和 PostgreSQL 關系型數據庫的性能。我們將運行一系列測試，其中 第一項測試 重點關注 數據寫入（ingestion）效率。

首先，我們會測量：

• 數據插入請求的延遲，使用 p99 百分位數 進行評估
• 數據庫的吞吐量，即每秒可處理的 請求數和插入數
• 數據庫的飽和度（saturation），即數據庫的負載情況，在這里我們主要關注：
• CPU 使用率
• 內存使用率

此外，我們還會測量：

• 磁盤寫入操作數
• 數據庫在磁盤上的存儲效率

值得一提的是，這兩種數據庫在這些方面的差異 非常大。

最后，我們將評估 數據庫的連接池（connection pool），觀察它們如何管理插入數據的連接。

在 第二項測試 中，我們將測量 數據讀取（retrieval） 的效率。

我使用的是當前最新版本：

• PostgreSQL 17.0
• MySQL 9.0

測試設計

為了進行測試，我在 兩個數據庫 中分別創建了 兩張表，具體的 SQL 語句如下。

假設我們有一個 分析系統（analytics backend），用于記錄 用戶在網站上的行為，例如：

• 登錄
• 登出
• 搜索
• 將商品加入購物車

數據庫中有兩張表：

1. Customer 表
• 存儲用戶的 姓名、地址
• 設有 主鍵 ID
2. Event 表
• 設有 主鍵 ID
• 外鍵 指向 Customer 表的主鍵
• 記錄 用戶執行的操作類型（action type）

第一項測試：
我們將使用以下 SQL 語句插入數據，隨機生成客戶 ID 和操作類型。

第二項測試：
我們將在包含 約 7000 萬條記錄 的數據庫上執行 簡單的 JOIN 查詢：

• 隨機生成一個 event ID
• 查詢并連接 customer 表
• 返回用戶的姓名、地址和操作類型

如果你有任何關于 改進測試設計 的建議，請告訴我！

代碼概覽

在客戶端編寫方面，我選擇使用 Golang，因為：

• Golang 是一門流行的編程語言
• 它擁有成熟的數據庫驅動庫

為了讓 MySQL 和 PostgreSQL 的測試盡可能公平，我使用 database/sql 接口 進行數據庫操作，而不是直接使用 pgx 驅動（盡管 pgx 可能會降低查詢延遲）。
但本次測試的重點是 對比數據庫本身的性能，而不是不同的驅動實現。

此外，我確保：

• 執行相同的 SQL 查詢
• 使用相同的數據庫連接配置

如果你有任何改進建議，請告訴我，或者更好的是，提交一個 Pull Request！

第一項測試：數據寫入

現在，我們開始 第一項測試。

這次測試 總共持續了近 3 小時，但我會將其壓縮至 幾分鐘 展示。
測試過程中，我們會：

• 部署多個客戶端
• 逐步增加負載
• 持續向數據庫發送請求
• 每 60 秒增加一個虛擬客戶端

你可以在 右上方的圖表 看到 每秒查詢數（QPS），而 左側圖表 顯示的是 從客戶端測量的插入延遲。

測試結果：

• 從一開始，PostgreSQL 的插入延遲明顯低于 MySQL
• MySQL 插入數據的時間幾乎是 PostgreSQL 的兩倍
• PostgreSQL 的 CPU 使用率更低，意味著它有更大的吞吐能力
• PostgreSQL 占用的內存也更少

最大區別：

• MySQL 需要更多的磁盤操作來存儲相同數量的記錄
• PostgreSQL 在磁盤上的存儲效率更高
• PostgreSQL 執行的磁盤操作更少，數據占用空間也更小

連接池情況：

• 兩個數據庫的連接池最終都達到了 80 個連接
• 每個客戶端的最大連接數設置為 40
• 每個數據庫有 2 個客戶端在不斷生成負載

臨界點：

• 當 QPS 達到 5,500 時，MySQL 開始跟不上 PostgreSQL
• MySQL 的延遲和 CPU 使用率激增，導致整體性能下降
• 當 QPS 達到 12,000 時，我為 PostgreSQL 額外添加了一個客戶端
• 最終，PostgreSQL 最高可處理 19,000 QPS（4 核 CPU + 直連 SSD）
• MySQL 最高只能處理 10,000 QPS，約為 PostgreSQL 的一半

第一項測試：數據分析

現在，我們查看 整個測試期間的數據：

1. 每秒查詢數（QPS）

1. 插入延遲（客戶端測量）

1. CPU 使用率

1. 總插入記錄數

• PostgreSQL 插入 約 6500 萬條記錄
• MySQL 插入 約 5000 萬條記錄
• 在第二項測試前，我會為 MySQL 增加一些記錄，使數據量一致

1. 內存使用

1. 磁盤寫入操作

1. 連接池大小

1. 數據庫大小
• PostgreSQL 存儲數據的 磁盤效率更高
• CPU 和磁盤操作占用更少
• PostgreSQL 在數據寫入方面明顯優于 MySQL

第二項測試：數據讀取

在運行 第二項測試 之前，我為 MySQL 額外添加了一些記錄，使其與 PostgreSQL 的數據量保持一致。

測試內容：

• 查詢 event 表中的數據
• 通過 event ID 進行 JOIN
• 返回用戶的姓名、地址和操作類型
• 測試前，重啟兩個數據庫，以清除緩存

磁盤讀取數據問題：

• 由于可能的配置錯誤，我沒有獲取到 PostgreSQL 的磁盤讀取數據
• 但我仍然有 MySQL 的磁盤操作數據

測試結果：

• 延遲差距不像第一項測試那么大
• 但 PostgreSQL 仍然比 MySQL 低延遲
• MySQL 的 CPU 使用率 顯著高于 PostgreSQL
• 這個趨勢一直持續，直到 MySQL 達到 CPU 使用瓶頸，性能下降

臨界點：

• 當 QPS 達到 18,000 時，MySQL 的性能下降更明顯
• MySQL 的延遲出現波動，而 PostgreSQL 仍然保持穩定
• 當 QPS 達到 20,000 時，MySQL 無法再處理更多查詢
• 我為 PostgreSQL 額外增加了一個客戶端，加速測試
• 最終，PostgreSQL 在 32,000 QPS 時達到 90% CPU 使用率，開始下降

結論：

• 在數據寫入和讀取方面，PostgreSQL 都比 MySQL 更高效
• 如果你有任何改進建議，例如更改客戶端代碼或測試設計，請告訴我！

第二項測試：數據分析

現在，我們查看 整個測試期間的數據：

1. 每秒查詢數（QPS）

1. 數據讀取延遲

1. CPU 使用率

1. 內存使用

1. 數據庫連接數

1. 磁盤讀取操作