要使用哪种类型的数据库记录ID：long还是guid？

Question

近年来，我使用的是MSSQL数据库，表中所有唯一记录的ID列类型为bigint（long）。它是自动增量，通常 - 工作正常。

目前我观察人们更喜欢使用GUID来记录身份。

将bigint交换为guid以获取唯一记录ID是否有意义？

我认为没有意义，因为生成bigint以及排序总是比guid更快，但是...当使用两个（或更多）分离的应用程序和数据库实例并保持同步时会遇到一些麻烦，所以你必须管理sql服务器之间的id池（例如：sql1使用从100到200的id，sql2使用从201到300的id） - 这是一个薄薄的冰。 使用guid id，你不关心id池。

您对我的镜像应用程序（和数据库）的建议是什么：保留传统ID或转移到GUID？

预先感谢您的回复！

Answer 1

guids有

优点：

• 能够从数据库脱机创建它们而不必担心碰撞。
• 你永远不会用完它们

缺点：

• 顺序插入可能表现不佳（尤其是在聚簇索引上）。
  • Sequential Guids修复了这个
• 每行占用更多空间
• 干净利落地创造一个并不便宜
  • 但如果客户端正在生成它们，这实际上没问题

该列应该仍然具有唯一约束（作为PK或作为单独约束，如果它是某些其他关系的一部分），因为没有什么能阻止某人手动提供GUID并且意外/故意违反唯一性。

如果空间没有打扰你，你的表现如果没有受到明显影响，他们会让很多问题消失。该决定不可避免地针对申请的个人需求。

Answer 2

我在涉及复制或客户端ID生成的任何方案中使用GUID。使用GUID在任何一种情况下管理身份都要容易得多。

对于双层场景，例如直接与数据库交谈的Web应用程序，或者不需要复制的服务器（或者可能只需要在一个方向上复制，pub / sub样式），我认为是自动递增ID列就好了。

至于是否继续使用autoincs或转移到GUIDs ......在绿色领域的应用程序中提倡GUID是一回事，你可以事先做出所有这些决定。建议某人迁移现有数据库是另一回事。它可能比它的价值更痛苦。

Answer 3

GUID在发生页面拆分时会出现性能和并发性问题。 INT可以100％运行页面填充 - 仅在一端添加，GUIDS在任何地方添加，因此您可能必须运行较低的填充 - 这会浪费整个索引的空间。

GUIDS可以在应用程序中分配，因此App可以知道它将创建的记录的ID，这可以很方便;但是，从技术上讲，可以生成重复的GUID（长赔率，但至少在GUID列上放置一个唯一索引）

我同意合并数据库更容易。但对我来说，直接的INT更好，然后在实际需要的时候解决如何合并DB的麻烦。

Answer 4

如果您的数据经常移动，那么GUID是表格Key的最佳选择。 如果你真的关心性能，只需坚持使用int或bigint

如果要利用上述两者，请使用int或bigint作为表的键，每行可以有一个rowguid列，这样数据也可以轻松移动而不会失去完整性。

Answer 5

如果要在查询字符串中显示ID，请使用Guids，否则请使用long作为规则。