是否有兴趣知道在一个Azure SQL性能级别上导致同一查询失败但在更高级别上起作用的潜在原因？
在标准级别，查询确实将服务器的最大利用率提高到100％，但是如果这是问题，我希望获得与内存不足有关的异常。但是相反，我得到了
无法创建大小为8075的行，该行大于允许的最大行大小为8060
我知道查询需要进行优化，但是对于这个问题，我感兴趣的是提高到Premium 150DTU会突然使相同数据不超过最大行大小吗？
答案 0 :(得分：1)
我可以就您的问题做出有根据的猜测。当您从一种保留大小更改为另一种保留大小时，优化器可用的资源也会更改。它认为它有更多的内存，特别是。内存是查询优化器中的查询成本计算的关键组成部分。发生在较小预留空间中的计划选择可能具有试图在tempdb中创建对象的假脱机或排序。保留大小较高的那个不是。由于无法实现中间表，因此这在存储引擎中受到了限制。
如果不查看计划，就不能确定地说这是所选查询计划的要求还是仅仅是优化。但是，您可以尝试在查询上使用NO_PERFORMANCE_SPOOL提示，以查看它是否适用于较小的保留大小。 （鉴于它的内存较少，我想这不是问题所在。）
https://docs.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-query?view=sql-server-2017
（由于我不知道您拥有哪种应用程序，但我会根据一般建议来猜测，但它基于我经常看到的正常模式）： 如果您的架构确实很宽或定义不正确，请考虑修改表定义以将列的大小减小到正确的最小值。对于数据仓库应用程序，请考虑使用维度表+代理键。如果要将文本日志文件转储到SQL中，然后尝试区分它们，请注意，distinct通常会暗示一种排序，如果行太宽，则可能导致此类问题（因为您尝试使用表中的所有列键）。
让您的应用正常运行的好运。对于关系型应用程序，SQL通常会非常适合您，您需要仔细考虑架构的详细信息并对其进行索引。将来，请发布有关您的查询模式，架构和查询计划的更多详细信息，以便其他人可以更准确地为您提供帮助。