最有效的UUID列类型是什么

为了存储128位UUID，有多种存储选项：

1. 字节[16]列
2. 两个bigint / long（64位）列
3. CHAR（36）列-32个十六进制数字+ 4个破折号。
4. UUID数据库特定的列（如果数据库支持）

从索引的角度来看，哪些是最有效的？如果数据库不支持专用的uuid类型，则1，2，3中的哪一个是最佳候选者？

专用uuid类型是PostgreSQL的最佳选择。对于其他DB来说很难说-有人隐含uuid的存储类型比简单字节类型的存储效率要低。

同样，在PostgreSQL中，bytea如果您没有uuid类型，那将是存储UUID的一种合理方法。对于其他DB，这取决于它们如何存储二进制数据。

在可能的情况下，我极力避免使用带破折号的十六进制。比较，排序和存储效率较低。

的确，“不是（2）或（3）”。曾经 在支持的情况下使用（4），否则使用（1）。

优先顺序：4,1,2,3如果使用SQL Server，请不要使用UUID作为聚簇键，不仅会造成严重的碎片，而且所有非聚簇索引中都使用了聚簇键，并将这些字节添加到每个索引行。可以通过使用NEWSEQUENTIALID减轻碎片，但通常比GUID更喜欢为Clustering Key设置宾果身份，以防止其他索引膨胀。

选择1比2的差异将取决于数据库在单列固定数组上处理两列基本类型的效率如何。使用伪数据进行测试应该足够容易。查看查询的速度以及索引和数据的大小。小+快是最好的！

人们必须假设，与作为该产品的客户端可以放在一起的任何数据相比，产品中任何本机支持的数据类型都将得到更好的优化。在那之后，任何具有最小字节数的内容都可以使每页获得最大的行数。