Azure，中间表上的聚集索引和性能影响

Question

我一直在将我的本地 SQL Server 移植到 Azure。将其移植到 Azure 并进行细微调整后，我注意到我的同步存储过程现在需要更长的时间。 当前设置是首先调用各种 Web 服务以将数据下载到中间表（这是一个常规表，而不是临时表或表变量，因为我需要所有 Web 服务的表）在所有这些 Web 服务完成后，我们得到该表中大约有 25K 条记录。

一旦中间表准备好，我就会调用我的同步存储过程，它只做很少的计算并更新这个中间表中的几个列。更新中间表后，它会删除主表并插入新值。 此存储过程在 Azure 上大约需要 5 分钟，而在以前的系统上需要 30 秒。我已经尝试了通常的无锁定表和使用汇总表等，但没有太大改进。查看执行计划后，我注意到我的瓶颈正在扫描和更新聚集索引。我确实需要在我的主数据表上使用这个聚集索引，因为它驱动了很多过程，但绝对不需要在我的中间表上使用这个聚集索引。中间表的聚集/主列在中间表的初始计算期间从未被更新，但是它占用了整个更新过程的 40%。

Azure 确实需要在每个表上都使用聚集索引，当您将它放在中间表上时，它会对性能造成很大影响。我想不出任何办法来改善这个瓶颈，如果你能给我任何反馈，我将不胜感激。

更新 更新过程越来越慢，最终到了锁定整个数据库的地步。经过几个小时的挖掘，我发现了以下内容：

SQL Azure - One session locking entire DB for Update and Insert

http://social.technet.microsoft.com/Forums/en-US/c3003a28-8beb-4860-85b2-03cf6d0312a8/substantial-increase-in-sereplslowsecondarythrottle-wait-type-to-the-point-we-cant-perform-any

备份数据库并在另一台 Azure 服务器上恢复后，该问题似乎自行解决。云高可用性就这么多，或者正如上面帖子中所说的那样：

“所以本质上，使 Sql Azure 高度可用的方面是导致数据库随机变得不可用。如果它没有杀死我们，我会嘲笑这个讽刺。”

Answer 1

您是否尝试过使用人工键，使用递增标识列作为聚集索引？如果您不断地将具有另一个值的页面拆分为聚集索引，则可能有助于索引维护。不断增加的索引作为集群会减少这种情况。