提前抱歉，因为这个问题与其他问题相似（但不一样！）。
无论如何，我需要能够在多个位置生成代理键，以便以后同步。我正在考虑使用 GUID，但是这些键可能必须出现在 URL 的参数中，并且 GUID 会非常复杂和丑陋。
我正在考虑一个允许我使用整数的方案，在数据库中提供更好的性能，但显然我不能简单地使用自动数字。这个想法是使用具有两种含义的键——我相信它被称为高低策略。密钥将由源（生成它的位置，通常在此业务案例中的 2 个位置中的 1 个）和自动递增值组成。例如：
1-000000567, 1-000000568, 1-000000569, 1-000000570, ...
对于另一个来源：
2-000000567, 2-000000567, ...
这也意味着我可以将它们作为整数存储在数据库中（即“2-000000567”将变为整数“2000000567”）。
任何人都可以看到这有什么问题吗？比如可能出现的索引或碎片？或者甚至是更好的方法？
只是为了确认一下，这个键没有商业意义，用户永远不会看到它（除了可能在 URL 的参数中）也不会使用它。
我期待您的意见并感谢您的时间，谢谢一百万:)