我们有一个Azure SQL数据库。直到几周前,我们设置的DTU为10(S0)。最近,我们遇到了更多的SQL超时错误,促使我们将DTU增加到50(S2)。我们收到的错误不那么频繁,但偶尔仍然会出现。当我们遇到这些超时时,我们会看到资源图上的峰值达到100%。进一步分析发现,通常是数据I/O操作导致峰值。但是当我们检查查询性能洞察时,没有列出的查询显示它们使用了那么多的资源。
另一个需要注意的事项是我们的数据库大小稳步增长。现在大约为19 GB,其中大部分(18 GB)来自一个包含很多长JSON字符串的表。超时错误通常发生在一个具有多个连接的特定查询上,但它们不与包含长字符串的表进行交互。
我们测试了复制数据库并删除所有长字符串,结果在10 DTU时没有任何超时,在50 DTU下的负载时间与包含所有长字符串的数据库相同。
我们已经重建了索引,虽然有所帮助,但仍然遇到超时错误。
鉴于超时查询未涉及包含长字符串的表,长字符串的表是否仍可能是DTU使用量的罪魁祸首?是否与SQL缓存有关?长字符串是否占用缓存并导致大量数据I/O?(它们也相当频繁地被访问。)
另一个需要注意的事项是我们的数据库大小稳步增长。现在大约为19 GB,其中大部分(18 GB)来自一个包含很多长JSON字符串的表。超时错误通常发生在一个具有多个连接的特定查询上,但它们不与包含长字符串的表进行交互。
我们测试了复制数据库并删除所有长字符串,结果在10 DTU时没有任何超时,在50 DTU下的负载时间与包含所有长字符串的数据库相同。
我们已经重建了索引,虽然有所帮助,但仍然遇到超时错误。
鉴于超时查询未涉及包含长字符串的表,长字符串的表是否仍可能是DTU使用量的罪魁祸首?是否与SQL缓存有关?长字符串是否占用缓存并导致大量数据I/O?(它们也相当频繁地被访问。)