我有一个运行约100K请求/小时的Azure网站，它连接到Azure SQL S2数据库，吞吐量约为8GB/天。我花了很多时间优化数据库索引、查询等。通常情况下，Data IO、CPU和Log IO的百分比在20%的范围内表现良好。
最近的一部分数据吞吐量被保留以支持我们的客户。我有一个夜间维护程序，删除过时的数据以管理数据库大小。除了删除varbinary(max)字段中的图像blobs外，这通常工作得很好。
夜间过程有一个循环，一次将10个记录varbinary(max)字段设置为null，等待几秒钟，然后设置下一个10。这个循环每晚的总数大约是2000。
这个循环将运行大约45 - 60分钟，然后停止运行，没有返回到我的远程Sql Agent作业，也没有报告错误。需要第二次，有时是第三次运行该过程才能完成将所需blobs设置为null。
为了减轻夜间过程的负载，我开始在一天中每30秒运行一次作业——它每次将一个blob设置为null。
通常情况下，涓流作业是好的，运行在1 - 6秒。然而，一天中有一两次出了问题，我找不到任何解释。数据I/O百分比峰值为100%，并保持30 - 60分钟或更长时间。这会导致数据库响应能力下降，网站性能也随之下降。涓流作业也会报告这段时间的运行情况。如果我停止Sql Agent作业，它可能需要几分钟才能停止，但数据I/O在30 - 60分钟的时间内保持100%。
web服务请求和数据库需求在整个工作日中相对稳定——没有不稳定的需求可以解释这一点。没有数据库死锁或其他错误报告。这就好像数据库遇到了某种积压限制，它的保持能力突然下降，然后它无法赶上，直到堵塞的东西最终被清除。然后性能会突然恢复正常。
你知道是什么导致了这种间歇性和不可预测的问题吗?当这些事件之一发生时，我可以通过查看什么来确定为什么数据I/O在很长一段时间内是100%的，您知道吗?谢谢你。
如果使用的是SQL DB V12，还可以考虑使用Query Store特性来解决此性能问题。现在在公开预览。
要打开查询存储，只需运行以下语句:
ALTER DATABASE your_db SET QUERY_STORE = ON;