&

性能比拼: MySQL vs PostgreSQL

當(dāng)前位置：點(diǎn)晴教程→知識(shí)管理交流 →『技術(shù)文檔交流』

admin

2025年4月8日 23:58 本文熱度 181

本內(nèi)容是對(duì)知名性能評(píng)測(cè)博主 Anton Putra MySQL vs PostgreSQL Performance Benchmark (Latency - Throughput - Saturation)^[1] 內(nèi)容的翻譯與整理, 有適當(dāng)刪減, 相關(guān)指標(biāo)和結(jié)論以原作為準(zhǔn)

MySQL vs PostgreSQL 數(shù)據(jù)庫(kù)性能對(duì)比

在本內(nèi)容中，我們將對(duì)比 MySQL 和 PostgreSQL 關(guān)系型數(shù)據(jù)庫(kù)的性能。我們將運(yùn)行一系列測(cè)試，其中 第一項(xiàng)測(cè)試 重點(diǎn)關(guān)注 數(shù)據(jù)寫(xiě)入（ingestion）效率。

首先，我們會(huì)測(cè)量：

數(shù)據(jù)插入請(qǐng)求的延遲，使用 p99 百分位數(shù) 進(jìn)行評(píng)估
數(shù)據(jù)庫(kù)的吞吐量，即每秒可處理的 請(qǐng)求數(shù)和插入數(shù)
數(shù)據(jù)庫(kù)的飽和度（saturation），即數(shù)據(jù)庫(kù)的負(fù)載情況，在這里我們主要關(guān)注：

CPU 使用率
內(nèi)存使用率

此外，我們還會(huì)測(cè)量：

磁盤(pán)寫(xiě)入操作數(shù)
數(shù)據(jù)庫(kù)在磁盤(pán)上的存儲(chǔ)效率

值得一提的是，這兩種數(shù)據(jù)庫(kù)在這些方面的差異 非常大。

最后，我們將評(píng)估 數(shù)據(jù)庫(kù)的連接池（connection pool），觀察它們?nèi)绾喂芾聿迦霐?shù)據(jù)的連接。

在 第二項(xiàng)測(cè)試 中，我們將測(cè)量 數(shù)據(jù)讀?。╮etrieval） 的效率。

我使用的是當(dāng)前最新版本：

PostgreSQL 17.0
MySQL 9.0

測(cè)試設(shè)計(jì)

為了進(jìn)行測(cè)試，我在 兩個(gè)數(shù)據(jù)庫(kù) 中分別創(chuàng)建了 兩張表，具體的 SQL 語(yǔ)句如下。

假設(shè)我們有一個(gè) 分析系統(tǒng)（analytics backend），用于記錄 用戶在網(wǎng)站上的行為，例如：

登錄
登出
搜索
將商品加入購(gòu)物車(chē)

數(shù)據(jù)庫(kù)中有兩張表：

Customer 表

存儲(chǔ)用戶的 姓名、地址
設(shè)有 主鍵 ID

Event 表

設(shè)有 主鍵 ID
外鍵指向 Customer 表的主鍵
記錄 用戶執(zhí)行的操作類(lèi)型（action type）

第一項(xiàng)測(cè)試：
我們將使用以下 SQL 語(yǔ)句插入數(shù)據(jù)，隨機(jī)生成客戶 ID 和操作類(lèi)型。

第二項(xiàng)測(cè)試：
我們將在包含 約 7000 萬(wàn)條記錄 的數(shù)據(jù)庫(kù)上執(zhí)行 簡(jiǎn)單的 JOIN 查詢：

隨機(jī)生成一個(gè) event ID
查詢并連接 customer 表
返回用戶的姓名、地址和操作類(lèi)型

如果你有任何關(guān)于 改進(jìn)測(cè)試設(shè)計(jì) 的建議，請(qǐng)告訴我！

代碼概覽

在客戶端編寫(xiě)方面，我選擇使用 Golang，因?yàn)椋?/span>

Golang 是一門(mén)流行的編程語(yǔ)言
它擁有成熟的數(shù)據(jù)庫(kù)驅(qū)動(dòng)庫(kù)

為了讓 MySQL 和 PostgreSQL 的測(cè)試盡可能公平，我使用 database/sql 接口 進(jìn)行數(shù)據(jù)庫(kù)操作，而不是直接使用 pgx 驅(qū)動(dòng)（盡管 pgx 可能會(huì)降低查詢延遲）。
但本次測(cè)試的重點(diǎn)是 對(duì)比數(shù)據(jù)庫(kù)本身的性能，而不是不同的驅(qū)動(dòng)實(shí)現(xiàn)。

此外，我確保：