核心用法
本技能为 PostgreSQL 数据库开发与运维提供端到端的工程化指南，涵盖从 Schema 设计到生产运维的全生命周期管理。
Schema 与数据类型：推荐使用现代 PG13+ 特性，如 BIGINT GENERATED ALWAYS AS IDENTITY 替代 SERIAL，TIMESTAMPTZ 处理时区，JSONB 存储半结构化数据，以及专用的网络/范围类型。强制要求外键索引、NOT NULL 约束、数据库级 CHECK 校验，并通过触发器管理 updated_at 而非依赖应用层。
迁移安全：采用不可变迁移原则，区分 Schema 变更（快速、事务性）与数据回填（慢速、需分批）。核心模式为"扩展-迁移-收缩"（Expand-Contract）：先添加新结构并双写，再切换读取，最后删除旧结构。高危操作包括无 DEFAULT 的 NOT NULL 约束（锁表重写）、非 CONCURRENTLY 索引创建（阻塞写入）、以及大数据量回填需使用 FOR UPDATE SKIP LOCKED 分批处理。
索引策略：B-tree 用于等值/范围查询，GIN 用于 JSONB containment 与全文检索，GiST 用于几何与范围数据，BRIN 用于自然有序的大表。复合索引遵循最左前缀原则，善用部分索引、覆盖索引（INCLUDE）与表达式索引。提供未索引外键检测查询，并建议定期清理 idx_scan = 0 的闲置索引。
高级特性：RLS（行级安全）通过策略表达式实现细粒度权限，需注意性能优化——将函数调用包装为标量子查询以避免每行求值。分区适用于亿级表，支持 RANGE（时序）、LIST（分类）、HASH（均匀分布）。pgvector 扩展提供 HNSW/IVFFlat 向量索引，用于 AI 嵌入检索。
查询与运维优化：强制使用 EXPLAIN (ANALYZE, BUFFERS) 分析执行计划，监控 pg_stat_statements 慢查询与表膨胀（dead tuples）。推荐游标分页替代 OFFSET，近似计数替代 count(*)，物化视图缓存复杂聚合。连接池强制使用 PgBouncer transaction 模式，注意 prepared statement 在连接池中的生命周期问题。
显著优点
1. 工程化成熟度极高：迁移模式、零停机部署、安全 DDL 等方案直接来自大规模生产实践
2. 版本前瞻性：针对 PG13-PG15+ 现代特性（NULLS NOT DISTINCT、gen_random_uuid()、identity columns）提供明确指导
3. 性能工具链完整：从索引选择、查询重写到表膨胀监控、死锁检测形成闭环
4. AI 就绪：原生支持 pgvector 向量检索，覆盖 RAG 应用的数据库层需求
潜在局限
1. PostgreSQL 专属：部分特性（如 CONCURRENTLY 索引、SKIP LOCKED）为 PG 特有，迁移至 MySQL/MariaDB 需重写
2. 版本门槛：部分推荐（gen_random_uuid()、HNSW 索引）需 PG13+，旧版本需降级方案
3. 运维深度依赖：RLS 性能陷阱、连接池模式选择、WAL 调优等需 DBA 经验，非开箱即用
适合人群
- 需要构建高可靠、可演进数据架构的后端工程师与架构师
- 负责亿级表性能优化与分区设计的 DBA
- 开发 AI 应用需集成向量检索的工程师
- 追求零停机部署的 DevOps/SRE 团队
常规风险
- 锁竞争：长事务阻塞 vacuum、大表 DDL 操作导致写入停滞
- RLS 性能退化：策略表达式未优化导致全表扫描，或策略逻辑绕过预期权限
- 连接池配置错误：transaction 模式下误用 session 特性（ advisory locks、temp tables）引发不可预期行为
- 迁移事故：编辑已部署迁移、跳过 expand-contract 模式直接重命名/删除列导致生产故障
- pgvector 资源消耗：HNSW 索引内存占用高，大维度向量未预过滤导致查询性能劣化