azure - 为什么我的表id跳了？

Question

我有一个简单的移动服务，它接受唯一标识符，然后创建一行或使用给定行的最近访问权限更新表中的现有行。截至今天，列表中有 XX 条条目(大于 10 条，小于 100 条)。 ID 顺序递增得很好，并且脚本没有抛出任何错误。

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

为什么会发生这种情况？为什么要跳？有没有办法解决它(特别是不擦 table )？我怎样才能防止这种情况再次发生？

Answer 1

我被链接到 Azure MSDN forums 中的先前条目。帖子的最后是这样的回复:

Good news (sort of); I talked to somebody at MSFT and he cleared the air a bit. I will share with you what he said:

• The TF 272 option won't work in Azure

• The behavior (reseed) is by design, but has been acknowledged internally as less than optimal and a request has been made (again, internally) to change the behavior. This may or may not happen.

• The reseed is triggered by instance bounces, which are covered by the SLA. They are mostly patches to the OS or SQL Azure itself.

The most important point was that, chances are, we will never hit the int limit. I think we all are forgetting (at least I did) that SQLAzure is not like SQL Server; there are very real limits in place, specifically total db size (150 gigs). He also said there is a max row limit per table of 10 million records, but I'm not finding documentation of that on the web. Assuming that is correct, even with jumps of 1000k, we would still be safe. And yes you could also switch to a bigint if you hit the int limit before the total db size limit. His point was simply that we will run out of room before we hit the int limit.

It isn't ideal for sure, but I'm no longer concerned about hitting an int limit.

Hopefully that helps some people here.

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