Agent Skills
返回列表
PostgreSQL 数据库设计

PostgreSQL 数据库设计

开发编程 更新于 2026.08.30

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3651d062/postgresql-design。

技能介绍

你在纠结什么

PostgreSQL 表一多，命名、类型、索引和外键很容易各写各的：SERIAL 和 IDENTITY 混用、金额用 FLOAT、时间用无时区 TIMESTAMP、子表外键没索引导致父表 DELETE 拖垮整表。分区、JSONB、逻辑复制和版本差异（例如 PG15 的 NULLS NOT DISTINCT）又往往要翻文档才能对齐设计决策。

技能怎么帮你落地

当意图是设计表结构、索引/查询优化、分区与分表、逻辑复制/主从、JSONB 半结构化设计，或「如何设计 xxx 的数据库」时，Agent 会按固定路径推进：先核对目标 PostgreSQL 版本（加载 version-major 与对应 version-X.Y 参考），再套用硬规则与命名规范。

核心约定包括：每张表具备 id（BIGINT GENERATED ALWAYS AS IDENTITY）、created_at / updated_at（TIMESTAMPTZ）；表名复数下划线、约束与索引前缀（uq_、idx_、fk_ 等）；金额用 NUMERIC(18,2)，JSON 用 JSONB 并按查询加 GIN；外键列必须手动建索引。索引选型会区分 B-tree、复合、Partial、Expression、GIN/GiST/BRIN 等场景。详细规范与 DDL 模板从 references/ 按需加载（设计规范、使用指南、最佳实践、业务 Schema 模式）。

边界与注意点

内容以官方文档与社区实践为准，不编造特性。单表约 2000 万行或 10GB 才作为分区经验阈值，实际仍要看访问模式。物理删除需自行评估合规；默认倾向软删除（deleted_at）。自增 ID 的序列间隙、MVCC 死元组与 VACUUM 策略属于运维范畴，设计阶段会提示但不会替代你的容量与备份方案。

使用场景

  • 新业务上线前，需要把订单、用户、支付等实体落成符合命名与类型规范的 PostgreSQL DDL，并补齐主键与时间戳字段。
  • 线上慢查询排查时，要判断该加复合 B-tree、Partial 还是 GIN，并确认 JSONB 查询字段是否已有合适索引。
  • 单表数据量逼近千万级，需要按时间或租户设计分区策略，并评估 BRIN 与时序字段是否更划算。
  • 搭建读写分离或灾备时，要梳理逻辑复制、主从拓扑与表结构变更对复制链路的影响。

适合人员

  • 负责新服务数据模型的后端工程师，希望每张表统一 `IDENTITY` 主键、`TIMESTAMPTZ` 与外键列索引，避免上线后锁表事故。
  • DBA 或全栈维护者，经常收到「这条 SQL 很慢」，需要按 SKILL 里的索引类型表快速给出可执行的优化方向。
  • 做 SaaS 多租户产品的架构师，要在 JSONB 存扩展属性同时保证高频查询字段有 GIN，并规划软删除与合规删除策略。
  • 从 MySQL 迁到 PostgreSQL 的技术负责人，需要对照版本特性文档避开废弃用法，并落地分区与复制方案。