我们有一个Azure SQL数据库。直到几周前，我们被设置为10个DTU（S0）。最近，我们遇到了更多的SQL超时错误，促使我们将DTU增加到50（S2）。我们得到错误的频率降低了，但偶尔也有。当我们得到这些超时时，我们看到资源图上的峰值达到100％。深入了解这一点，通常是数据I / O操作使之达到峰值。但是，当我们检查Query Performance Insight时，没有列出的查询表明它们在使用那么多资源。
要注意的另一件事是，我们的数据库大小稳定增长。现在大约有19 GB，其中大部分（18 GB）来自其中包含许多长JSON字符串的一个表。超时错误通常会在具有多个联接的某个查询上发生，但它们不会与带有长字符串的表进行交互。
我们测试了复制数据库并删除所有长字符串的过程，并且在10 DTU时没有任何超时，但是与所有在50 DTU时的长字符串一样的数据库执行了与加载时间相同的操作。
我们重建了索引，尽管有所帮助，但我们仍然遇到超时错误。
鉴于获得超时的查询未触及长字符串表，长字符串表是否仍可能是DTU使用的罪魁祸首？它与SQL缓存有关吗？长字符串会占用缓存并导致大量数据I / O吗？ （它们也经常被访问。）
答案 0 :(得分：0)
如果字符串很热（如您所说），它们肯定会耗尽您的缓存预算。当热工作集超出RAM缓存大小时，性能可能会下降（10-100倍）。那是因为IO比RAM访问慢10-1000倍。这意味着即使高速缓存命中率略有下降（例如1％），也可能会造成很大的性能损失。
这个悬崖可能非常陡峭。该应用程序运行良好的一刻，下一次IO消失了。
由于Azure SQL数据库具有严格的资源限制（如我所听到和阅读的那样），因此这可能会很快耗尽您购买的限制性能。
我认为您进行的测试可以确认字符串是导致问题的原因。您可以尝试将字符串隔离在其他地方吗？如果它们很冷，请将其移至另一张桌子。如果它们很热，请将其移动到另一个数据存储（数据库或NoSQL）。这样一来，您就可以回到较低的层次。