2

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

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

为什么会这样？为什么要跳？有没有办法解决它（尤其是不擦桌子）？我怎样才能防止这种情况再次发生？

4

2 回答 2

3

我已链接到Azure MSDN 论坛中的上一个条目。在线程的末尾是这个响应：

好消息（有点）；我和 MSFT 的某个人谈过话，他稍微澄清了一下。我将与您分享他所说的：

  • TF 272 选项在 Azure 中不起作用

  • 行为（重新播种）是设计使然，但已在内部确认为不是最佳的，并且已提出（再次在内部）更改行为的请求。这可能会或可能不会发生。

  • 重新播种由 SLA 涵盖的实例反弹触发。它们主要是操作系统或 SQL Azure 本身的补丁。

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

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

希望这可以帮助这里的一些人。

所讨论的“reseed”基本上是“current id index”的重新初始化。基本上，每当 sql 响应出现反弹时，它都会跳一段安全距离，以确保有可用的 id。

于 2013-08-07T22:02:22.223 回答
0

表中的id字段是使用 IDENTITY 属性和（种子，增量）对的 (1,1) 值创建的 - 您可以通过在 SQL Server Management Studio 中打开移动服务使用的数据库来检查这一点，选择表，右键单击它，然后选择 Script Table as --> CREATE To --> New Query Editor Window。所以这些值应该加一。默认情况下，IDENTITY_INSERT 属性设置为 OFF（如果您尝试使用设置了标识字段的管理工作室在表上插入数据，则会收到错误消息）。

我能想到的唯一可能导致这种大跳跃的事情是，如果数据被插入然后在表中删除。如果 的下一个值是 X，并且您插入 Y 元素并立即删除它们，那么即使所有 Y 元素都已删除id，下一个值将是 (X + Y)。id你的情况可能发生过这种情况吗？

于 2013-08-07T20:40:07.877 回答