主键选择直接影响PostgreSQL的性能与存储效率。1. 整型主键（如BIGSERIAL）因空间小、顺序插入高效，适合大多数场景；2. UUID主键虽全局唯一但体积大、随机性强，易引发页分裂和写入瓶颈，建议使用时间优先的uuid_generate_v7()缓解问题；3. 复合主键适用于自然键场景，但字段过多会增加索引宽度和I/O开销；4. 自增主键支持顺序写入，减少随机IO，而随机主键导致缓存失效和WAL压力上升；5. 主键决定表数据物理存储顺序，影响聚集性，单调递增主键利于顺序写但可能造成热点争用；6. 建议优先使用BIGSERIAL或IDENTITY作为代理主键，分布式环境可选ULID或时间优先UUID，避免长字符串或复杂类型作主键；7. 可通过CLUSTER命令优化物理存储，提升范围查询效率。合理设计主键需结合业务模式、访问特征及负载测试，确保数据完整性与系统性能平衡。
在PostgreSQL中，主键的选择不仅关乎数据完整性，更直接影响查询性能、索引效率和存储结构。主键作为表的核心标识，其设计策略需要结合业务场景、数据增长模式以及访问模式综合考量。一个不合理的主键可能导致索引膨胀、写入热点、锁竞争甚至全表扫描等性能问题。
主键类型对B-Tree索引的影响
PostgreSQL默认使用B-Tree索引来支持主键约束。B-Tree的性能与键值的大小、排序性和唯一性密切相关。
- 整型主键（如SERIAL/BIGSERIAL）：占用空间小（4字节或8字节），比较和排序效率高，是大多数场景下的首选。自增特性保证了插入时的有序性，有助于减少页分裂和索引碎片。
- UUID主键：虽然全局唯一且适合分布式系统，但16字节的长度显著增加索引体积，随机性导致频繁的页分裂和缓存失效，影响写入性能。尤其在大表中，UUID主键可能使索引大小翻倍甚至更多。
- 复合主键：由多个字段组成，适用于自然键场景。但字段越多，索引越宽，不仅增加I/O开销，还可能降低JOIN和WHERE条件的执行效率。
自增主键 vs 随机主键：写入性能对比
自增主键（如IDENTITY或SERIAL）在插入新记录时通常追加到索引末尾，这种“顺序写”模式对B-Tree非常友好，能有效利用缓冲区并减少随机IO。
- 使用SERIAL时，新值总是大于已有值，索引页局部性好，缓存命中率高。
- 而UUID（尤其是版本4）具有高度随机性，插入位置不确定，容易引发页分裂，导致WAL日志增多和vacuum压力上升。
- 若必须使用UUID，可考虑使用uuid_generate_v7()（时间优先UUID）以提升插入局部性。
主键与表物理存储的关联（CLUSTERING）
PostgreSQL中，主键自动创建唯一索引，且该索引决定了表中数据的物理存储顺序（即堆表的逻辑顺序）。这意味着主键选择直接影响数据的聚集程度。
- 如果主键是单调递增的，新行会集中写入最后一个数据页，有利于顺序写入，但也可能造成热点页争用，特别是在高并发插入场景下。
- 若按时间戳或范围查询频繁，选择时间相关字段作为主键前缀可提升范围扫描效率。
- 注意：即使设置了主键，PostgreSQL不会自动保持物理顺序。可通过CLUSTER命令手动重排表数据，但需定期维护。
主键策略建议与最佳实践
合理选择主键应基于应用需求和性能目标，避免教条化使用某一种类型。
- 优先使用BIGSERIAL或IDENTITY列作为代理主键，尤其在单体数据库或读多写少场景中。
- 在分布式环境中，若需避免协调服务生成ID，可采用ULID或时间优先UUID替代传统UUID。
- 避免使用长字符串或JSON字段作为主键，这类类型不仅占用空间大，且排序成本高。
- 对于历史归档表或只读表，可考虑使用分区键与主键一致的设计，提升查询剪枝能力。
基本上就这些。主键不是随便选的，它牵动整个表的性能命脉。理解不同类型主键的行为特征，结合实际负载测试，才能做出最优决策。
