Advantages and disadvantages of GUID / UUID database keys我曾经在许多数据库系统上工作过，如果所有数据库键都是guid/uuid值，那么在数据库之间移动条目就容易得多。我已经考虑过沿着这条路径走几次了，但是总是有一些不确定性，特别是关于性能和不可通过电话读取的URL。 是否有人在数据库中广泛使用guid？这样做会有什么好处？可能的陷阱是什么？ 优势：
缺点：
就我个人而言，我在任何一个相当大的系统中使用它们，但是我在一个在各地复制的系统上接受了"培训"，所以我们必须拥有它们。YMMV。 我认为重复数据的事情是垃圾-你可以得到重复的数据，无论你怎么做。代孕钥匙通常不适合我在哪里工作。不过，我们确实使用了类似WordPress的系统：
更新：所以这个得到+1’ed很多，我想我应该指出guid-pk的一个大缺点：聚集索引。 如果您有很多记录，并且在一个guid上有一个聚集索引，那么当您在项目列表中的任意位置(即要点)插入时，您的插入性能将很糟糕，而不是在末尾(即快速插入)。 因此，如果您需要插入性能，可以使用auto inc int，如果您想与其他人共享它，可以生成一个guid(即，在URL中显示给用户)。 @ Matt Sheppard： 假设你有一张顾客桌。当然，您不希望客户不止一次出现在表中，否则整个销售和物流部门都会出现很多混乱(尤其是当客户的多行包含不同的信息时)。 因此，您有一个客户标识符，它唯一地标识客户，并且您确保客户知道该标识符(在发票中)，以便客户和客户服务人员在需要通信时有一个共同的参考。为了确保没有重复的客户记录，可以通过客户标识符上的主键或客户标识符列上的非空+唯一约束向表添加唯一性约束。 接下来，由于某种原因(我想不起来)，您需要向customer表中添加一个guid列，并将其作为主键。如果"客户标识符"列现在没有唯一性保证，那么您将在整个组织中请求未来的问题，因为guid始终是唯一的。 一些"架构师"可能会告诉您"哦，但是我们在我们的应用层中处理真正的客户唯一性约束！"对。关于通用编程语言和(特别是)中间层框架的时尚一直在变化，而且通常不会超出数据库的实际使用范围。而且，在某些情况下，您很有可能需要访问数据库而不必经过当前的应用程序。=麻烦。(但幸运的是，您和"架构师"早就不在了，所以您不会在那里清理这些混乱。)换句话说：在数据库中(以及其他层，如果您有时间的话)要保持明显的约束。 换言之：向表中添加guid列可能是有充分理由的，但请不要掉以轻心，因为这样会降低您在真实(=non-guid)信息中保持一致性的野心。 主要的优点是，您可以在不连接到数据库的情况下创建唯一的ID。ID是全局唯一的，因此您可以轻松地组合来自不同数据库的数据。这些似乎是小优势，但在过去为我节省了很多工作。 主要缺点是需要更多的存储空间(在现代系统中不是问题)，并且ID不是真正的人类可读的。调试时这可能是一个问题。 存在一些性能问题，如索引碎片。但是这些都是容易解决的(JimmyNillson的combinguids:http://www.informit.com/articles/article.aspx？p＝25862) 编辑合并了我对此问题的两个答案 @MattSheppard我想他是说你可以用不同的guid复制行作为主键。这是任何类型的代理键的问题，而不仅仅是guid。正如他所说，通过向非键列添加有意义的唯一约束，很容易解决这个问题。另一种选择是使用一把自然钥匙，而那些钥匙确实有问题。 为什么没人提到表演？当您有多个连接时，所有的连接都基于这些讨厌的guid，性能将通过地板，一直到：( 如果将guid用作"uniqifier"，让复制的数据进入表中，那么将来guid可能会给您带来很多麻烦。如果要使用guid，请考虑在其他列上仍然保持唯一的约束。 如果您还将该列用作聚集索引(一种相对常见的做法)，那么还需要考虑将guid用作主键的另一个小问题。由于guid的性质，插入时不会按顺序开始，因此插入时它们将是分页符等。只是需要考虑的一点，如果系统将有高IO… 主键ID与guid 作为主键的guid的成本(SQL Server 2000) 神话，guid与autoincrement(mysql 5) 这是你真正想要的。 UID PROS
GUID CONS
有一件事情没有真正解决，即使用随机(Uuidv4)ID作为主键会损害主键索引的性能。无论您的表是否围绕键聚集，都会发生这种情况。 RDBMS通常确保主键的唯一性，并确保通过键进行查找，这种结构称为btree，它是一种具有较大分支因子的搜索树(二进制搜索树的分支因子为2)。现在，一个连续的整型ID将导致插入只发生在树的一侧，使大多数叶节点保持不变。添加随机UUID将导致插入将整个索引的叶节点拆分。 同样，如果存储的数据大部分是暂时的，那么通常情况下，需要访问最新的数据并将其与最新的数据连接起来。使用随机UUID，模式将不会从中受益，并且会命中更多的索引行，因此需要在内存中使用更多的索引页。对于顺序ID，如果最新的数据是最需要的，那么热索引页将需要更少的RAM。 |
