我有一个简单的移动服务，它接受一个唯一的标识符，然后创建一行或更新表中具有给定行的最新访问权限的现有行。直到今天，列表中有XX个条目（大于10，小于100）。 ID正在按顺序递增，并且脚本没有抛出任何错误。
然后，突然从XX到100YY跳跃，最后几个条目继续沿着这个指数。在这段时间内，日志中记录了一个错误 - 超时。
为什么会这样？为什么跳？有没有办法解决它（特别是没有擦桌子）？我怎样才能防止这种情况再次发生？
答案 0 :(得分：3)
我被链接到Azure MSDN forums中的上一个条目。在线程的最后是这个回复：
好消息（有点）;我和MSFT的某个人谈过，他清理了一下空气。我将与你分享他所说的话：
- 中不起作用
TF 272选项在Azure
行为（重新设定）是设计使然，但在内部已被确认为不是最佳状态，并且已经（再次，内部）请求更改行为。这可能会也可能不会发生。
重新启动是由实例退回触发的，SLA涵盖了这种情况。它们主要是操作系统或SQL Azure本身的补丁。
最重要的一点是，很可能，我们永远不会达到int限制。我想我们都忘记了（至少我做过）SQLAzure不像SQL Server;有非常实际的限制，特别是总数据库大小（150演出）。他还说，每张表有1000万条记录的最大行数限制，但我没有在网上找到这方面的文档。假设这是正确的，即使跳跃1000k，我们仍然是安全的。是的，如果在总db大小限制之前达到int限制，你也可以切换到bigint。他的观点很简单，我们在达到int限制之前会耗尽空间。
这绝对不是理想的，但我不再担心达到int限制。
希望这能帮助一些人。
讨论的'reseed'基本上是'当前id索引'的重新初始化。基本上，只要有sql响应的反弹，它就会跳过一个安全的距离，以确保有一个可用的id。
答案 1 :(得分：0)
表中的id字段是使用IDENTITY属性创建的，其中（种子，增量）对的值为（1,1） - 您可以通过打开移动服务使用的数据库来检查SQL Server Management Studio，选择表，右键单击它，然后选择Script Table as - ＆gt;创建到 - ＆gt;新查询编辑器窗口。所以值应该加1。默认情况下，IDENTITY_INSERT属性设置为OFF（如果您尝试使用设置了标识字段的管理工作室在表上插入数据，则会收到错误。）
我能想到的唯一可能导致这种大跳跃的事情是，如果插入数据然后在表中删除。如果id的下一个值为X，并且您插入Y个元素并立即删除它们，则id的下一个值将为（X + Y），即使所有Y个元素都有被删除了。你的情况会发生这种情况吗？