performance - 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 高度可用的方面是导致数据库随机不可用。如果它没有杀死我们，我会 mock 这个讽刺。”

Answer 1

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