结合你之前关注的分布式系统高并发写入、MySQL/PostgreSQL索引性能优化的相关背景，两者虽然
都是128位的全局唯一标识符，但是底层位分布逻辑的本质差异，直接决定了它们在数据库B+树索引
体系里的表现天差地别，哪怕在相同硬件、相同数据量的场景下，写入吞吐量、索引体积、查询性能都
能拉开数倍的差距。
核心差异根源：位分布逻辑完全不同
两者的128位空间填充策略从根源上就走向了两个完全相反的方向：
UUID v4 是完全随机生成的128位值，除了固定占用的6位版本号、变体号之外，剩下的122位全部由随
机数填充，生成的ID在整个128位空间里完全离散分布，没有任何规律可言。
UUID v7 在前48位嵌入了毫秒级Unix时间戳，中间6位固定为版本号和变体号，剩下的74位才填充随机
数，生成的ID天然具备严格的时间有序性，新生成的ID数值一定比之前的ID更大。
数据库表现差异的底层机制
数据库的主键索引几乎都是B+树结构，这种数据结构天生对有序数据极度友好，两者的特性差异直接在
B+树的运行逻辑里被放大：
写入性能的天壤之别
UUID v4的完全随机特性，导致每次新插入的ID都会落在B+树索引的完全随机位置，几乎每次写入都会触发
索引页分裂，InnoDB的索引填充因子被迫降到70%以下，大量磁盘IO被浪费在索引页的重组上。实测在
MySQL聚集索引场景下，插入100万条v4数据的耗时是v7的2倍以上，PostgreSQL千万级批量导入场景下，
v7的耗时仅为v4的40%，WAL写放大从v4的19倍直接降到2.5倍。
索引体积与碎片率差异巨大
有序的UUID v7写入时，新数据只会集中追加到B+树索引的最右侧叶子节点，索引页可以被填充满到90%以
上，几乎不会产生无效碎片，最终生成的索引体积比v4小30%左右。而v4随机写入产生的大量索引碎片，会导
致相同数据量下索引占用的磁盘空间大幅膨胀，缓存命中率大幅下降，范围查询性能甚至能拉开数倍差距。
业务场景适配性完全不同
UUID v4的完全随机特性，在极低并发、不需要大范围范围查询的场景下可以正常使用，但在订单系统、日志
存储、时序数据这类高频插入、经常按创建时间做范围查询的场景下，UUID v7的有序性可以直接命中B+树的
连续叶子节点，范围查询性能比v4提升数倍，同时还保留了UUID跨分布式节点生成、无需中心化发号器的核
心优势，还避免了v1版本泄露MAC地址的隐私问题。
生产环境选型避坑要点
在MySQL中使用v7时，一定要调用UUID_TO_BIN(id, 1)函数做存储优化，第二个参数设为1可以把时间戳字
段调整到二进制的高位，进一步提升索引的有序性，写入性能还能再提升20%-40%；PostgreSQL 18之后原生
内置了uuidv7()生成函数，直接作为主键默认值即可，不需要额外的转换处理。
需要我为你生成MySQL和PostgreSQL下UUID v7作为主键的完整建表+性能压测脚本，直接运行就能对比出
两者的实际性能差异吗？
0 评论