代码之家 › 专栏 › 技术社区 › Ircover

MS SQL CXPACKET超时

sql-server

Ircover · 技术社区 · 4 年前

我们有SQL Server 2016(v13.0.4206.0),默认情况下对并行性没有限制——SQL想要的任何计数。而且它没有引发任何问题。。。直到现在。

对于另一个功能,我们的应用程序中出现了一个意外引发超时异常的书面查询。当它成功执行并将每个查询的最大线程数设置为1时,我感到非常惊讶。是的,6秒的查询时间不是很好,即使考虑到大部分时间都花在了获取上,但这离3分钟的超时时间还差得很远!

顺便说一句,尽管有并行设置,但使用SQLServerManagementStudio执行此查询始终有效。与数据库的连接似乎有问题,但所有其他查询都正常工作,即使比那个查询困难得多。

我们的应用程序是基于ASP。NET Core 3.0(不知道是否重要),数据库连接是使用 System.Data.SqlClient v4.8.0 。我所能确定的是,为此查询创建了这么多任务:

我试着看着处决 sys.dm_os_waiting_tasks (感谢谷歌)。我不确定我是否做对了,但似乎任务 context_id 0-8被那些有 context_id 9-16,反之亦然。死锁的明显例子,不是吗?但是,SQL Server如何在没有我的“帮助”的情况下管理线程呢?或者我做错了什么?

以防万一一些不恰当的答案:

由于我们的应用程序中存在一些繁重的查询,我不会关闭并行性(将每个查询的最大线程数设置为1)作为解决方案;
我不想提高 Cost Threshold for Parallelism 设置是因为我担心另一个查询(猜测是更重的查询)也会出现同样的问题。所以我只想确定真正的原因;
优化查询不再被考虑,因为根据实际的执行计划,我无法让它更快——有足够的索引。但在一些非常重要的争论之后,我准备重新思考。

所以, 我的问题是 :为什么我没有要求的并行性会破坏查询执行?我该如何避免这种情况?

0 回复 | 直到 4 年前

gotqn user3521065 4 年前

确实,有时引擎选择使用并行执行(或不使用)会导致性能下降。

您不想控制服务器选项和成本,因为您不确定这将如何反映到其他查询中,这是可以理解的。

如果您确定,您的查询将在不并行处理的情况下更好地执行,您可以使用以下命令为其指定选项 query hints -MAXDOP是这样的:

SELECT ...
FROM ...
OPTION (MAXDOP 1);

这很容易,如果需要,你可以回滚。此外,您不会影响其他查询。

你是说:

根据实际执行计划,不再考虑优化查询。。。

执行计划有时会产生误导。首先,您可以保存执行计划并使用打开它 SentryOne Plan Explorer -它是免费的,可以让你更好地了解正在发生的事情。

此外,如果一个查询执行了3秒或6分钟,那么它一定有问题,或者可能是数据库的活动。如果它在HttpClientalways中执行得很快,则可能是引擎使用了正确的缓存计划。我认为最好共享查询本身,并附加两个计划(串行和并行),然后花更多时间对其进行调优。