@SqlMenace
GUID存在其他问题，因为GUID不是顺序的，所以插入将分散在各处，这会导致页面分裂和索引碎片化。
这并不完全正确。 主键!=聚集索引。
如果聚集索引是另一列（例如“inserted_on”），则插入将是顺序的，并且不会发生页面分裂或过度碎片化。
inserted_on不是唯一的，SQL Server将在聚集索引（幕后）添加一些“唯一化”的额外字节。此外，请注意，created_on可能会生成碎片，因为行可以按照与客户端中创建时不同的顺序插入到聚集索引中。虽然不确定这是否适用于OPs问题，但对于已同步的数据库，需要注意这一点。 - Christian Davén我只是想指向Sequential Guid相对于标准Guid的性能改进是什么？，它涵盖了GUID的讨论。
为了人类可读性，考虑分配机器ID，然后使用这些机器的顺序号作为可能性。这将需要管理机器ID的分配，可以在一列或两列中完成。
我个人喜欢SGUID的答案。
你说得没错，这是一个老问题，有两个经典的解决方案：
使用唯一标识符作为主键。请注意，如果您关心可读性，可以自己生成唯一标识符而不是使用GUID。唯一标识符将使用日期和机器信息生成唯一值。
使用“Actor”+标识符的复合键。每个用户都有一个数字演员ID，并且新插入行的键使用演员ID以及下一个可用标识符。因此，如果两个演员都使用ID“100”插入新行，则不会违反主键约束。
就我个人而言，我更喜欢第一种方法，因为我认为复合键作为外键真的很繁琐。我认为人类可读性的抱怨被夸大了——最终用户无论如何都不需要知道您的键的任何信息！
确保使用guid.comb - 它会处理索引问题。如果在此之后您遇到性能问题，那么很快您将成为扩展方面的专家。
使用GUID的另一个原因是为了实现数据库重构。假设您决定对Customers实体应用多态性或继承等功能。现在，您希望Customers和Employees从Person派生，并共享一个表。拥有真正独特的标识符使数据迁移变得简单。没有序列或整数标识字段需要处理。
使用GUID键肯定比标准整数键慢（并且占用更多内存），但这是否是一个问题取决于您的系统将承受的负载类型。根据您后端DB的不同，索引GUID字段可能存在问题。
使用GUID简化了一整类问题，但代价是部分性能和调试能力——在那些测试查询中输入GUID会变得老套。
除了 GUIDs，你能想到其他解决离线计算机同步新数据回中央数据库时发生的"合并"的方法吗？我的意思是，如果键是整数(INTs)，基本上在导入时就必须重新编号。使用 GUID 可以避免这种情况。
使用GUID在我们需要将两个数据库合并成一个时，节省了我们大量的工作。