PostgreSQL 的共享内存

PostgreSQL 的共享内存（尤其是 `shared_buffers`）对性能的影响非常关键，但它不是“越大越好”，而是需要在**缓存命中率、内存管理开销、操作系统缓存协同**之间找到平衡点。

---

### ✅ **正面影响：显著提升性能**
| 机制 | 性能提升表现 |
|------|---------------|
| **减少磁盘 I/O** | 将热数据缓存于 `shared_buffers`，避免频繁读盘，可提升查询响应速度数倍。 |
| **提高并发能力** | 共享内存中统一管理锁、事务状态，减少进程间通信开销，提升并发处理能力。 |
| **降低延迟** | 对于读多写少的 OLAP 系统，适当增大 `shared_buffers` 可显著降低查询延迟。 |

---

### ⚠️ **负面影响：设置不当反而拖慢性能**
| 问题 | 原因 |
|------|------|
| **DROP/TRUNCATE 变慢** | 删除表时需遍历整个 `shared_buffers`，复杂度为 O(N)，N = shared_buffers/8KB，越大越慢。 |
| **启动变慢** | `shared_buffers` 越大，初始化内存区域时间越长。 |
| **操作系统缓存被挤压** | PostgreSQL 的缓存与 OS page cache 是“双层结构”，`shared_buffers` 过大会压缩 OS cache，反而降低整体缓存命中率。 |
| **内存浪费或 swap** | 设置过大可能导致系统内存紧张，触发 swap，性能急剧下降。 |

---

### ✅ **最佳实践：如何设置 shared_buffers**
- **推荐起点**：设为物理内存的 **25%–40%**。
- **OLTP 系统**：建议 25% 左右，避免 DROP/TRUNCATE 性能退化。
- **OLAP 系统**：可适当提高（如 40%），以缓存更多热数据。
- **验证方式**：
- 使用 `pg_buffercache` 查看缓存命中率。
- 使用 `pgbench` 或实际业务负载测试不同配置下的 TPS/QPS 变化。

---

### ✅ 总结一句话：
> 共享内存是 PostgreSQL 性能的核心杠杆，**合理设置可带来数倍性能提升**，但**过大反而因管理开销和缓存冲突导致性能下降**，需结合业务负载和系统资源精细调优。