中型 RC 中的单个查询导致 Azure 专用 SQL 池中的 CPU 达到 100%答案

【问题标题】：Single Query in Medium RC Causing CPU to 100% in Azure Dedicated SQL Pool中型 RC 中的单个查询导致 Azure 专用 SQL 池中的 CPU 达到 100%
【发布时间】：2021-04-17 08:25:37
【问题描述】：

我们之前在专用 SQL 池中有一个用户自己将 CPU 提高到 100%。我们认为这是由于她的查询有多个子查询并且属于中等资源类。但是，我们无法告诉执行计划。我们通常以 500 DWU 运行，它有 20 个并发槽，中等 rc 有两个槽。

如果查询有 4 或 5 个子查询，我们是否应该期望该查询总共占用 10 个并发槽？另外，我们如何看待执行计划？看起来和普通的 SQL 不太一样。

谢谢！

【问题讨论】：

标签： azure-synapse

【解决方案1】：

很难判断子查询是否是真正的罪魁祸首。对我来说，我认为数据起着更大的作用。对于执行计划，不知道你有没有经历过这个doc，应该会有所帮助。

【讨论】：

那么，您的想法是数据移动/改组导致 CPU 出现主要峰值？是的，我们以前使用过这篇文章，但每次我们都必须在分析完成之前扩大规模，以免影响业务。我承认有问题的表有超过十亿行。我们计划在几个小时后重新运行查询，以便在那时进行查询分析，以查看可能导致问题的活动。
一旦我们得到结果，我会更新这个帖子。谢谢！
我们确实在那个周末进行了测试。示例查询在 60 秒内运行。此外，我们还运行了 5 个额外的并发。我们确实看到，中型 RC 中的每个查询都占用了 60% 的计算量。我们没有意识到的是，我们可能没有在查询活动中看到所有正在运行的查询。这有延迟吗？我怀疑查看所有查询的唯一保证方法是通过这个 DMV？ docs.microsoft.com/en-us/azure/synapse-analytics/…
由于大量数据洗牌，CPU 出现峰值。我们最终确实为专用 SQL 池与 Microsoft 团队开了一张票。我们正在尝试与数据分析师最终用户一起决定进行一些查询效率分析是否有意义。谢谢！