我一直在将我的本地SQL Server移植到Azure。将其移植到Azure并进行微调后，我注意到我的同步存储过程现在需要更长的时间。 当前的设置是通过调用各种Web服务来将数据下载到中间表（它是常规表而不是临时表或表变量，因为我需要所有Web服务的表）所有这些Web服务之后完成后，我们在此表中获得约25,000条记录。
中间表准备就绪后，我调用了我的同步存储过程，它只进行了少量计算，并在此中间表中更新了几列。更新中间表后，它会删除主表并插入新值。 此存储过程在Azure上大约需要5分钟，而之前的系统需要30秒。我已经尝试了通常的No Lock on table和使用汇总表等但没有太大的改进。在查看执行计划后，我注意到我的瓶颈正在扫描并更新聚簇索引。我确实需要在我的主数据表上使用这个集群索引，因为它驱动了大量的过程，但绝对不需要在我的中间表上使用这个聚簇索引。在初始计算中间表期间，中间表聚簇/主列不会被更新，但它占整个更新过程的40％。
Azure确实需要在每个表上使用聚簇索引，并且当您将其放在中间表上时，它会受到很大的性能影响。我想不出任何方法来改善这个瓶颈，如果你能给我任何反馈，我将不胜感激。
更新 更新过程越来越慢，最终达到了锁定整个数据库的程度。经过几个小时的挖掘，我发现了以下内容：
SQL Azure - One session locking entire DB for Update and Insert
备份数据库并在另一台Azure服务器上恢复后，问题似乎已解决。云高可用性或者如上文所述：
＆＃34;因此，实质上使Sql Azure高度可用的方面导致数据库变得随机不可用。如果它不能杀死我们，我会嘲笑讽刺。＆＃34;
答案 0 :(得分：0)
您是否尝试过使用递增标识列作为聚簇索引使用人工密钥？如果您经常将具有其他值的页面拆分为聚簇索引，则可能有助于索引维护。作为集群的不断增加的索引会减少这一点。