我一直在将我的本地 SQL Server 移植到 Azure。将其移植到 Azure 并进行细微调整后，我注意到我的同步存储过程现在需要更长的时间。当前设置是首先调用各种 Web 服务以将数据下载到中间表（这是一个常规表，而不是临时表或表变量，因为我需要所有 Web 服务的表）在所有这些 Web 服务完成后，我们得到该表中大约有 25K 条记录。
中间表准备好后，我调用我的同步存储过程，该过程执行少量计算并更新此中间表中的少量列。更新中间表后，它会删除主表并插入新值。此存储过程在 Azure 上大约需要 5 分钟，而在以前的系统上需要 30 秒。我已经尝试了通常的无锁定表和使用汇总表等，但没有太大改进。查看执行计划后，我注意到我的瓶颈正在扫描和更新聚集索引。我确实需要在我的主数据表上使用这个聚集索引，因为它驱动了很多过程，但绝对不需要在我的中间表上使用这个聚集索引。
Azure 确实需要在每个表上都有聚集索引，当你把它放在中间表上时，它会对性能造成很大影响。我想不出任何办法来改善这个瓶颈，如果你能给我任何反馈，我将不胜感激。
UPDATE 更新过程越来越慢，最终到了锁定整个数据库的地步。经过几个小时的挖掘，我发现了以下内容：
SQL Azure - 一个会话锁定整个数据库以进行更新和插入
备份数据库并将其还原到另一台 azure 服务器后，该问题似乎自行解决。对于云高可用性，或者正如上面帖子中所说的那样：
“所以本质上，使 Sql Azure 高度可用的方面是导致数据库随机不可用。如果它没有杀死我们，我会嘲笑这个讽刺。”