SQL Azure - 标准 50 DTU 时最大行大小超出错误，但相同查询在高级 150 DTU 时没有错误

Question

是否有兴趣了解幕后发生了什么导致同一查询在一个 Azure SQL 性能级别失败但在更高级别工作的情况？

该查询确实在标准级别将服务器最大化到 100%，但如果这是问题所在，我预计会出现内存不足相关的异常。但相反我得到了

Cannot create a row of size 8075 which is greater than the allowable maximum row size of 8060

我知道查询需要优化，但就这个问题而言，我感兴趣的是，提升到 Premium 150DTU 会突然使相同的数据不超过最大行大小吗？

Answer 1

我可以对您的问题做出有根据的猜测。当您从一种预留大小更改为另一种预留大小时，优化器可用的资源会发生变化。具体来说，它相信自己有更多的内存。内存是查询优化器中计算查询成本的关键组件。在较低预留大小中发生的计划选择可能有一个试图在 tempdb 中创建对象的假脱机或排序。预订量较大的则不是。由于中间表无法具体化，因此这遇到了存储引擎的限制。

如果不查看计划，就无法确定这是所选查询计划的要求还是仅仅是优化。但是，您可以尝试在查询上使用 NO_PERFORMANCE_SPOOL 提示，看看这是否使其适用于较小的预留大小。 (鉴于它的内存较少，我猜这不是问题)。

https://learn.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-query?view=sql-server-2017

(现在我猜测一般建议，因为我不知道你有什么样的应用程序，但它基于我经常看到的正常模式):如果您的架构确实很宽或定义不明确，请考虑修改您的表定义以将列的大小减少到正确的最小值。对于数据仓库应用，请考虑使用维度表+代理键。如果您将文本日志文件转储到 SQL 中，然后尝试区分它们，请注意，不同通常意味着一种排序，如果行太宽(因为您尝试使用 key )。

祝您的应用程序正常运行。对于关系型应用程序，SQL 往往非常适合您，在这些应用程序中您需要仔细考虑架构和索引的详细信息。将来，请发布有关您的查询模式、架构和查询计划的更多详细信息，以便其他人可以更准确地为您提供帮助。