序言

从 SQL 到生产：PostgreSQL 与 Pigsty 实战

为什么写这本书

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

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

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

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

这本书怎样展开

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

为什么值得解决
  → 需要建立什么心智模型
  → 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 对应分支。

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