我们当前的PostgreSQL数据库使用GUID作为主键，并将其存储为文本字段
我对此的最初反应是，尝试执行任何类型的最小笛卡尔连接都将是一场试图找到所有匹配记录的索引化噩梦。然而，也许我对数据库索引的有限理解在这里是错误的
我认为我们应该使用UUID，因为它们存储为GUID的二进制表示形式，而文本不是，并且在文本列上获得的索引量是最小的
这将是一个重大的项目来改变这些，我想知道这是否值得
处理UUID编号时，将其存储为数据类型UUID总是.根本没有理由考虑文本作为替代。默认情况下，输入和输出都是通过文本表示完成的。演员很便宜
数据类型text需要更多的RAM和磁盘空间，处理速度较慢，更容易出错@坎普森的回答提供了大部分理由。奇怪的是，他似乎没有得出相同的结论
这些问题以前都被问过、回答过、讨论过。dba.SE上的相关问题及详细说明：
- 当所有值都是36个字符时，char与varchar的索引查找速度会明显加快吗
- MD5字段的最佳数据类型是什么
bigint
也许你根本不需要uuid（guid）。考虑 BigIt 。它只占用8个字节，在各个方面都更快。它的范围经常被低估：
-9223372036854775808至+9223372036854775807
这是920万个正数。瞧，九千五百万二百二十三万三千三百七十二万亿三百六十六亿左右
如果你每秒烧掉一百万个ID（这是一个非常高的数字），那么你可以持续烧掉292471年。负数再过292471年。“几千万或几亿”甚至还不算接近
UUID实际上只适用于分布式系统和其他特殊情况