UUIDv6是UUIDv1的字段兼容版本，重新排序以改善数据库局部性。UUIDv6主要在使用UUIDv1的上下文中实现。不涉及遗留UUIDv1的系统应该改用UUIDv7。
与 UUIDv1 将时间戳分割成低、中、高三个部分不同，UUIDv6 改变了这一序列，使时间戳字节从最重要到最不重要存储。也就是说，给定一个如 UUIDv1 所指定的 60 位时间戳值，对于UUIDv6，首先存储前48位最重要的位，接着是4位版本（位置相同），然后是原始60位时间戳的剩余12位。
时钟序列和节点位保持在 UUIDv1 中的位置不变。
UUIDv1 和 UUIDv6 字段和位具体布局如下：
(表格顶部的两行数字用于表示位数，00,01,…,10,11,…,20,21,…,30,31)
UUIDv1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UUIDv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_high |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time_mid | ver | time_low |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var| clock_seq | node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
可以看出 UUIDv6 和 UUIDv1 的主要区别在于前 32 位是 time_low 还是 time_high。那为什么要做这种调整呢？
因为在 UUIDv1 中，时间戳的部分会被分割并分布在 UUID 的不同部分，这导致了在按时间顺序插入数据库时的非顺序性。这种非顺序性会影响数据库索引的效率，因为数据库需要频繁地重新排序数据以维持索引的顺序，从而降低了插入和查询的性能。而 UUIDv6 的调整其实就是按照正常顺序将时间戳填充到 UUID 的高 64 位，但是需要注意的是因为高 64 位中 ver 的存在，导致按时间生成的 UUIDv6 的前 64 位并非有序的，真正保持时间顺序的是 UUIDv6 的前 48 位。（当我们在数据库中为 UUIDv6 创建索引时，可以使用前缀索引，取 UUID 序列的前 6 个字节，以确保插入数据库时的顺序性）