使用UUID作为PostgreSQL主键的性能优化及相关疑问

1. UUID作为主键是否性能更差？ #

是的，随机UUID（比如你用的gen_random_uuid()）作为主键时，性能确实不如自增主键。核心原因在于：

• 随机UUID的无序性会导致主键索引（通常是B+树结构）频繁发生页分裂，每次插入都可能需要调整多个索引页，额外增加磁盘IO开销。
• 无序的主键值会降低数据库缓存命中率，新插入的数据分散在索引的不同位置，无法有效利用缓存空间。

不过你提到当前数据规模不大，这种性能差异在小数据量下很难感知，更多是理论层面的性能损耗。

2. 优化UUID主键的技巧 #

如果坚持用UUID作为主键，可以通过以下方式降低性能损耗：

• 使用有序UUID：比如UUIDv1（包含时间戳和MAC地址）或UUIDv7（专为有序性设计的新版本），这类UUID生成时带有时间顺序，插入时索引页分裂的概率大幅降低，性能接近自增主键。PostgreSQL中可以通过uuid-ossp扩展的uuid_generate_v1()生成UUIDv1，UUIDv7则可借助第三方扩展或自定义函数实现。
• 调整索引填充因子：对于PostgreSQL，将主键索引的fillfactor设置为80（默认是90），预留更多空间给新插入的数据，减少页分裂。执行命令：

  ALTER TABLE your_table ALTER COLUMN id SET STORAGE PLAIN;
  CREATE INDEX idx_table_id ON your_table(id) WITH (fillfactor=80);
  

• 批量插入数据：如果有大量数据需要插入，采用批量操作可以减少索引分裂的频率，提升整体插入效率。

3. 自增主键+UUID对外展示的方案是否有效？ #

这是生产环境中非常实用的方案，完全有效：

• 用自增序列（比如PostgreSQL的SERIAL或IDENTITY类型）作为内部主键，保证索引插入的高效性，关联查询时的性能也更优。
• 额外添加一个UUID字段（默认值设为gen_random_uuid()），对外提供这个UUID作为唯一标识，既避免了自增主键暴露业务数据（比如数据增长速度）的问题，又兼顾了内部数据操作的性能。
• 记得给UUID字段添加唯一索引，确保其唯一性：

  CREATE UNIQUE INDEX idx_table_uuid ON your_table(uuid_column);
  

4. 性能更优的类似替代方案 #

如果想要兼顾唯一性和性能，还有这些替代方案：

• 雪花算法（Snowflake）：生成64位的有序ID，包含时间戳、机器标识和序列号，可本地生成无需依赖数据库，性能极高，有序性也保证了索引的友好性。PostgreSQL可以通过自定义函数或第三方扩展实现雪花ID的生成和存储。
• ULID：格式兼容UUID，但生成的ID按时间顺序排列，插入性能远优于随机UUID，同时具备UUID的唯一性优势，多数编程语言都有成熟的库支持，数据库中可以用字符串或二进制类型存储。
• 自增ID加混淆前缀：如果不需要严格的UUID格式，可以给自增ID添加固定前缀或进行简单哈希混淆，既避免暴露自增规律，又保留了自增主键的性能优势，注意要保证最终生成的ID唯一。

内容的提问来源于stack exchange，提问作者Obvious_Grapefruit