分区与扩展生态
PostgreSQL 的生态优势来自两件事：声明式分区是内置能力，扩展体系让 PG 从关系库变成多模型平台。面试主线：分区解决什么问题，扩展生态里 PostGIS/pgvector/FDW 各是什么。
声明式分区
PG 10+ 原生支持声明式分区（RANGE/LIST/HASH），不需要外部工具：
CREATE TABLE events (...) PARTITION BY RANGE (created_at);
CREATE TABLE events_2026_01 PARTITION OF events
FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');核心收益：
- 分区裁剪：查询条件命中分区键时只扫描对应分区，是最大的性能收益
- 数据生命周期管理：按时间分区，过期分区直接 DETACH 归档，删除成本极低
- 每分区独立索引、独立 VACUUM
注意点：分区键要匹配查询模式（时间序列按时间分）；跨分区查询退化为 Append 扫描所有分区；分区过多（上千）会带来规划开销。分区是运维层面的优化，分库分表是架构层面的拆分，两者解决不同问题。
PostGIS
空间扩展的事实标准：geometry 类型、空间索引（GiST）、空间函数（距离、相交、缓冲区）、地理坐标系。选型地位：需要空间查询（附近的人、区域统计）时 PostGIS 是默认答案，MySQL 的空间能力远不及。
pgvector
向量检索扩展：vector 类型、三种距离、IVFFlat 和 HNSW 索引。RAG 场景轻量选择，见索引体系篇。
FDW：外部数据包装器
FDW（Foreign Data Wrapper）让 PG 能查询外部数据源，如查询另一个 PG（postgres_fdw）、MySQL、文件、甚至远端 API。用途：
- 跨库查询（替代部分分库分表场景的跨库 JOIN）
- 数据联邦：一张外部表映射到数仓
- 注意：FDW 查询性能有限，适合低频跨库访问，不适合高频 OLTP
扩展生态全景
| 扩展 | 解决什么 |
|---|---|
| PostGIS | 空间数据 |
| pgvector | 向量检索 |
| postgres_fdw | 跨库访问 |
| pg_repack | 在线重建表 |
| pg_stat_statements | 慢 SQL 统计（生产必装） |
| pgaudit | 审计日志 |
| timescaledb | 时序数据 |
生产必装 pg_stat_statements 监控慢 SQL，这是 PG 性能排查的入口。
面试追问
- 声明式分区有什么收益？ 分区裁剪只扫目标分区，生命周期管理（DETACH 归档），每分区独立维护。分区键要匹配查询模式
- 分区和分库分表什么关系？ 分区是单机内运维优化，分库分表是跨机架构拆分。分区解决不了写入吞吐瓶颈
- FDW 是什么？ 外部数据包装器，让 PG 查询外部数据源（另一个 PG、MySQL、文件）。跨库查询可用但性能有限
- PostGIS 的定位？ 空间扩展事实标准，GiST 索引支撑空间查询。需要空间能力时默认答案
- 生产必装的监控扩展？ pg_stat_statements，统计慢 SQL 和资源消耗，性能排查入口