# 七成正确的调优器：界定 pig pg tune 的边界

> 为什么 pig pg tune 只生成确定性的硬件相关核心参数，而不把自己包装成完整的生产 PostgreSQL 调优方案。

---

LLMS 索引： [llms.txt](/zh/llms.txt)

---

> **决策日期：** 2026-03-21<br>
> **状态：** 2026-03-23 实现，并随 [pig v1.3.2](/zh/release/pig-1.3.2/) 发布。<br>
> **当前参考：** [`pig pg tune`](/zh/pg/#pg-tune)<br>
> **范围：** 为单个本地 PostgreSQL 实例生成确定性的首轮配置，不是完整的生产设计服务。

## 决策 {#decision}

`pig pg tune` 只回答一个有边界的问题：给定 CPU 数量、内存、磁盘容量与工作负载画像，
这台机器的 PostgreSQL 核心参数应该采用怎样的合理起点？

它追求的是“七成正确”的初始值。命令尽可能探测硬件，允许显式覆盖，计算少量高影响参数，
并可以写入 `postgresql.auto.conf`。它不声称能够设计复制、持久性、安全、日志、扩展、连接池或工作负载相关 SQL 行为。

## 背景 {#context}

在还没有工作负载遥测时，运维人员仍然经常需要一套可用基线。复制静态配置会忽略机器规模；
完整调优服务则需要查询轨迹、存储特征、可用性目标和持续反馈。

PIG 已经能够定位 PostgreSQL 安装并以数据库操作系统用户运行命令。
一个小而确定的调优器符合这个边界，而且结果可检查、可复现。

## 考虑过的方案 {#alternatives}

- **发布一份万能配置。** 内存与并行参数必须随主机规模变化，因此否决。
- **构建自适应自动调优器。** 它需要遥测、实验、工作负载分类与回滚机制，远超本地 CLI 的边界。
- **重写主配置文件。** 这会把生成值混入发行版或运维人员维护的配置中，也不利于回滚。
- **调节所有 PostgreSQL 参数。** 很多参数表达业务、持久性、安全和拓扑决策，硬件无法替人决定。

## 契约 {#contract}

调优器遵循以下规则：

- 硬件探测过程可观察，每个探测值都可以覆盖；
- profile 改变公开公式，不依赖隐藏的外部状态；
- 相同输入产生确定性结果；
- 写文件之前可以预览，也可以获得结构化结果；
- 生成设置仅进入自动配置表面；
- 编辑器保留无关的现有设置与注释；
- 数值受 PostgreSQL 与机器资源边界约束；
- 输出明确声明 SSD 假设与建议局限。

## 影响 {#impact}

该命令适合开发机、新安装和初步容量规划，但不能证明生产数据库已经完成调优。
复制延迟、检查点行为、查询并发、缓存命中率、存储延迟、扩展与故障目标仍需要测量和人工判断。

保持小范围也让计算公式可以被充分测试，并让用户无需远程服务即可重现结果。

## 验证与演进 {#verification}

实现提交为
[`60eecfe`](https://github.com/pgsty/pig/commit/60eecfe045449e72d80986a0357fbe24b9e71f00)，
并标记为 v1.3.2。单元测试覆盖画像计算、硬件覆盖、结果渲染和安全的 `postgresql.auto.conf` 编辑。
之后的静态分析清理没有改变产品边界。

## 当前状态 {#status}

`pig pg tune` 仍是一项首轮工具。应用前应审阅结果；当拓扑、高可用、可观测性或安全需要协同设计时，
应使用 Pigsty 或基于真实工作负载的调优流程。当前参数与示例维护在 [`pig pg` 参考文档](/zh/pg/)中。