Azure 为什么我的桌子id跳了？

我有一个简单的移动服务，它接受一个唯一的标识符，然后在表中创建一行或使用对给定行的最新访问更新现有行。到今天为止，列表中有XX个条目（大于10个，小于100个）。ID按顺序递增，并且没有为脚本抛出任何错误

然后，突然间，从XX跳到了100YY，最后几个条目继续沿着这个索引。此时，日志中记录了一个错误-超时

---

为什么会这样？为什么要跳？有没有办法修复它（尤其是在不擦桌子的情况下）？如何防止这种情况再次发生？

表中的

id

字段是使用IDENTITY属性创建的，该属性具有（种子，增量）对的（1,1）值-您可以在SQL Server Management Studio中打开移动服务使用的数据库，选择表，右键单击它，并选择脚本表作为-->创建到-->新建查询编辑器窗口。所以这些值应该增加1。默认情况下，IDENTITY_INSERT属性设置为OFF（如果尝试使用设置了IDENTITY字段的management studio在表中插入数据，则会出现错误）

---

我所能想到的唯一一件可能导致这一大跳跃的事情是，如果在表中插入数据，然后删除数据。如果

id

的下一个值是X，并且您插入Y个元素并立即删除它们，那么

id

的下一个值将是（X+Y），即使所有Y个元素都已删除。在你的情况下可能会发生这种情况吗？

我被链接到。在线程的末尾是这样的响应：

好消息（有点）；我和微软金融公司的某个人谈过，他澄清了一点。我将与你分享他所说的话：

• TF272选项在Azure中不起作用

• 行为（重新设定种子）是经过设计的，但在内部已被确认为不太理想，并且已提出（再次，在内部）更改行为的请求。这可能发生，也可能不会发生

• 重新设定种子由实例反弹触发，该反弹由SLA覆盖。它们大多是操作系统或SQLAzure本身的补丁

最重要的一点是，我们很可能永远不会达到整数极限。我想我们都忘记了（至少我忘记了）SQLAzure不像SQLServer；有非常实际的限制，特别是总的数据库大小（150千兆）。他还说，每个1000万条记录的表有一个最大行数限制，但我在网上找不到这方面的文档。假设这是正确的，即使有1000k的跳跃，我们仍然是安全的。是的，如果在总db大小限制之前达到int限制，也可以切换到bigint。他的观点很简单，我们将在达到整数极限之前用完空间

这肯定不是很理想，但我不再担心达到int限制

希望这对这里的一些人有所帮助

---

讨论的“重新设定种子”基本上是“当前id索引”的重新初始化。基本上，每当sql响应反弹时，它都会跳转一段安全距离，以确保有可用的id。

感谢您的帮助！我被链接到似乎是答案的地方（实例反弹可能是由于OS或SQLAzure补丁）。