混合存储UUID V4与V7的列索引优化及数据类型选择

混合存储UUID v4与v7的索引收益分析 #

• 能获得部分索引优化收益，但效果不如全量使用UUID v7。
• UUID v7的二进制可排序特性，核心是让新写入记录的索引键按时间顺序递增，大幅减少B+树索引的页分裂和随机IO操作。即便列中存在旧的UUID v4数据，新写入的UUID v7数据会集中在索引的尾部区域，写入时无需频繁跨页调整，对新增数据的插入性能、以及按时间范围查询新数据的效率，都会有明显提升。
• 但旧的UUID v4数据仍会随机分布在索引结构中，涉及旧数据的查询无法享受到排序带来的优化，整体索引的碎片化程度也会高于全量使用UUID v7的场景。

UUID列的最优数据类型选择 #

• 不建议使用char(36)：该类型存储字符串格式的UUID，占用36字节存储空间，且字符串比较的效率远低于二进制类型，会拖累索引性能。
• 最优选择为二进制或数据库原生UUID类型：
  • 二进制类型：多数数据库支持binary(16)（如MySQL）或bytea（如PostgreSQL），直接存储UUID的16字节二进制形式，存储空间比char(36)减少一半以上，索引的存储、比较效率大幅提升。
  • 原生UUID类型：部分数据库提供原生uuid类型（如PostgreSQL的uuid、SQL Server的uniqueidentifier），底层基于二进制存储，同时支持字符串格式的转换，兼顾性能与可读性。

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