近几年在使用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？
提前感谢您的回复！
导游有
好处：
缺点：
该列仍应具有唯一约束（作为 PK 或如果它是某些其他关系的一部分，则作为单独约束），因为没有什么可以阻止某人手动提供 GUID 并意外/故意违反唯一性。
如果空间不会打扰您，并且您的表现如果没有受到显着影响，那么它们会使很多问题消失。该决定不可避免地取决于应用程序的个人需求。
我在涉及复制或客户端 ID 生成的任何场景中都使用 GUID。在任何一种情况下，使用 GUID 管理身份都容易得多。
对于像 web 应用程序直接与数据库对话这样的两层场景，或者对于不需要复制的服务器（或者可能只需要在一个方向上复制，pub/sub 样式），那么我认为一个自动递增的 ID 列很好。
至于是继续使用 autoincs 还是转向 GUID……在一个新的应用程序中提倡 GUID 是一回事，您可以在其中预先做出所有这些决定。建议某人迁移现有数据库是另一回事。这可能比它的价值更痛苦。
发生页面拆分时，GUID 会出现性能和并发性问题。INT 可以以 100% 的速度运行页面填充 - 仅在一端添加，GUIDS 在任何地方添加，因此您可能必须运行较低的填充 - 这会浪费整个索引的空间。
GUIDS可以在应用程序中分配，所以App可以知道它要创建的记录的ID，可以很方便；但是，从技术上讲，可能会生成重复的 GUID（可能性很大，但至少在 GUID 列上放置一个唯一索引）
我同意合并数据库更容易。但对我来说，直接的 INT 更好，然后忍受在实际需要时/如果需要时如何合并 DB 的麻烦。
如果您的数据经常移动，那么 GUID 是表键的最佳选择。如果您真的关心性能，请坚持使用 int 或 bigint
如果您想同时利用上述两种方法，请使用 int 或 bigint 作为表的键，并且每行可以有一个 rowguid 列，这样数据也可以轻松移动而不会丢失完整性。
如果要在查询字符串中显示 id，请使用 Guids，否则使用 long 作为规则。