如果有人知道幕后可能发生什么导致同一查询在一个 Azure SQL 性能级别失败但在更高级别工作，是否感兴趣？
该查询在标准级别将服务器最大化到 100%，但如果这是问题所在，我希望得到与内存不足相关的异常。但相反，我得到一个
无法创建大于允许的最大行大小 8060 的大小为 8075 的行
我知道查询需要优化，但对于这个问题，我感兴趣的是提升到 Premium 150DTU 会如何突然使相同的数据不超过最大行大小？
【问题讨论】：
标签： sql azure azure-sql-database
我可以对您的问题做出有根据的猜测。当您从一种保留大小更改为另一种时，优化器可用的资源会发生变化。它认为它有更多的内存，特别是。内存是查询优化器中查询成本的关键组件。在较低预留大小中发生的计划选择可能具有试图在 tempdb 中创建对象的假脱机或排序。保留大小较高的那个不是。这在存储引擎中遇到了限制，因为中间表无法实现。
如果不查看计划，就无法确定这是所选查询计划的要求还是仅仅是优化。但是，您可以尝试在查询上使用 NO_PERFORMANCE_SPOOL 提示，以查看这是否使其适用于较小的预留大小。 （考虑到它的内存较少，我猜这不是问题所在）。
https://docs.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-query?view=sql-server-2017
（现在我猜测一般建议，因为我不知道您拥有什么样的应用程序，但它基于我经常看到的正常模式）： 如果您的架构非常宽或定义不明确，请考虑修改表定义以将列的大小减小到正确的最小值。对于数据仓库应用，请考虑使用维度表+代理键。如果您将文本日志文件转储到 SQL 中，然后尝试区分它们，请注意，如果行太宽（因为您试图使用钥匙）。
祝您的应用正常运行。对于关系应用程序，SQL 往往非常适合您，您可以稍微考虑一下架构和索引的细节。将来，请发布有关您的查询模式、架构和查询计划的更多详细信息，以便其他人可以更准确地帮助您。
【讨论】：