# 序言

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

---

> 从 SQL 到生产：PostgreSQL 与 Pigsty 实战

## 为什么写这本书

PostgreSQL 并不缺功能说明，也不缺零散教程。真正稀缺的是一条完整的工程链：业务规则
怎样落成可靠的数据模型，SQL 为什么在并发下仍然正确，数据库怎样从一个进程变成可交付
的服务，出现故障时又怎样在保住数据和证据的前提下恢复。

很多问题正是断在这些接缝上：会写 SQL，却说不清连接落到了哪个实例；会建索引，却没有
证明慢时间花在执行而非等待；有高可用，却没有定义数据丢失边界；有备份，却从未在隔离
环境恢复；事故结束后写了复盘，却没有把教训固化成可验证控制。

这本书要补的是这些接缝。它面向已经掌握 Linux 与通用 SQL、希望系统完成 PostgreSQL
应用开发和生产落地的读者，从对象与模型开始，经过查询、并发、扩展、部署、运营和恢复，
最终形成三种能力：

1. **解释**：能用 PostgreSQL 原理说明现象为什么发生；
2. **行动**：能把目标拆成有前提、风险、步骤和停止线的操作；
3. **证明**：能用 SQL、目录、日志、指标和实验后验说明结果确实成立。

## 这本书怎样展开

全书不是命令大全，也不按功能菜单平铺。每章围绕一个工程问题，依次回答：

```text
为什么值得解决
  → 需要建立什么心智模型
  → PostgreSQL 提供了什么机制
  → 应当怎样操作
  → 用什么证据验收
  → 结论在哪些边界外不再成立
```

贯穿案例 `pg36_shop` 会持续演进。前几章建立对象、角色和业务模型；中段加入查询、
并发、发布与扩展；下卷再把同一套数据和工作负载放进高可用、备份、监控、容量、升级
与事故恢复中。这样做的价值不是让一个玩具应用假装覆盖所有生产场景，而是让前一章的
决定成为后一章可检查的输入。

实验也不是正文的装饰。凡是可以验证的结论，尽量给出正例、反例、运行证据和复位边界。
性能结果只在记录的硬件、数据、并发和时间窗内成立；破坏性动作只在明确可销毁的隔离
环境执行。读者最终应学会迁移方法，而不是背下某次示例输出。

## PostgreSQL 与 Pigsty

PostgreSQL 是全书的核心知识对象；Pigsty 是统一实验载体、观察窗口，也是把 PostgreSQL、
高可用、备份、接入与监控组合成生产服务的一种参考实现。

正文始终区分三层：PostgreSQL 原生机制、任何生产数据库平台都要承担的职责、Pigsty
对这些职责的具体实现。理解原生机制，才能判断平台自动化做对了什么；理解平台职责，
才能把书中的方法迁移到托管数据库、Operator 或其他自建方案。

## 作者关系与利益披露

作者是 Pigsty 的作者与维护者，因此对其设计、能力与使用方式拥有直接经验，也天然存在偏好。全书要求 Pigsty 结论尽量回到 PostgreSQL 原生 SQL、配置或组件证据验证，并在可能造成迁移误解的位置说明跨平台职责映射。

## 关于“36 计”

“36 计”表示 36 个递进的实战单元，是目录与教学节奏的品牌表达，不把章节强行附会为古代计策。事故篇优先使用功能标题检索，成语仅作为副标题。

## 怎样阅读

第一次系统学习，按 ch01 → ch36 顺序阅读；应用开发者可先完成上卷，再补 ch22、ch23
和 ch25；DBA、SRE 与平台工程师应先建立 ch01、ch02、ch05 的共同语言，再进入下卷。
事故现场不要从搜索结果中直接复制恢复命令：先读 ch31 建立分级、现场保护和决策边界，
再进入 ch32–ch35 对应分支。

每章开头给出目标、前置与版本边界，末尾给出验收。最有效的读法是先写下自己的判断，
再运行实验，最后用证据修正判断。能复述术语不等于掌握；能在陌生环境里重新确认前提、
执行步骤并解释结果，才是本书所说的工程能力。