PostgreSQL 与 MySQL 内存占用对比分析

核心摘要： 由于底层架构不同（多进程 vs 多线程），PostgreSQL 和 MySQL 在 Linux 系统命令（如 free 和 top）中的内存表现截然不同。

PostgreSQL： 内存主要体现为 共享内存 (Shared/Cached)。
MySQL： 内存主要体现为 已用内存 (Used)。

1. 架构差异根源

特性	PostgreSQL	MySQL (InnoDB)
进程模型	多进程 (Multi-Process) 主进程 fork 出子进程处理连接。	多线程 (Multi-Thread) 单进程 (mysqld) 内部产生线程处理连接。
内存共享方式	OS System V / MMAP 共享内存需向操作系统申请特殊的共享区域。	进程内堆内存 (Heap) 线程天然共享进程内的地址空间。
核心参数	`shared_buffers`	`innodb_buffer_pool_size`

2. 实战案例分析

案例 A：PostgreSQL 服务器 (4GB RAM)

配置：shared_buffers = 1500MB

$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3911         302         117        1545        3491        1797
    

现象： used 非常小 (302M)，但 buff/cache 巨大。
解读： PostgreSQL 的 1.5GB 缓存池并未计入 used，而是被 Linux 归类为 Shared Memory。
在 Linux 统计口径中，Shared Memory 属于 Cache 的一部分。
真实内存占用 ≈ used (302) + shared (1545) = 约 1.8GB。

案例 B：MySQL 服务器 (16GB RAM)

假设配置：innodb_buffer_pool_size = 4GB ~ 5GB 左右

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          15987        5324        4209          22        6453       10302
    

现象： used 很大 (5.3GB)，shared 极小 (22M)。
解读： MySQL 的 InnoDB Buffer Pool 直接通过 malloc 在堆上分配，被 Linux 视为进程的私有匿名内存，因此直接计入 used。
真实内存占用 = used (5324) (主要由 MySQL 贡献)。
注意： 此处 buff/cache 也有 6453M，这通常是操作系统的文件系统缓存 (Page Cache)，用于加速文件读写，并非 MySQL 专用的共享内存配置。

3. 运维监控指南

如何判断内存是否正常？

对于 PostgreSQL：

不要被很低的 used 迷惑，也不要被很高的 buff/cache 吓到。

关键指标： 关注 free 命令中的 shared 列。它应该接近你的 shared_buffers 配置值。
Top 命令： RES 包含了共享内存，多个 Postgres 进程的 RES 不能简单相加。

对于 MySQL：

内存实打实地显示在 used 中。

关键指标： 关注 used。如果 used 持续增长接近 Total，可能会触发 OOM。
Top 命令： 关注 mysqld 进程的 RES，它代表了数据库实际持有的物理内存。

4. 结论

在排查内存问题时，必须结合数据库类型来解读 Linux 命令输出：

看到 High Buff/Cache + High Shared → 通常是 PostgreSQL。
看到 High Used + Low Shared → 通常是 MySQL (或 Java 等应用)。