linq 和并行性 - SQL Server

Posted 2023-03-31

【中文标题】linq 和并行性 - SQL Server

【英文标题】：linq and parallelism - SQL Server

【发布时间】：2013-06-17 08:01:18

【问题描述】：

我在使用 LINQ To Entities 时遇到问题。

如果我运行我的 LINQ 查询，那么它会在执行计划中使用 Parallelism (Gather Streams and Reparation Stream)，这会导致大量 CXPACKET 等待。

但如果我将 LINQ 翻译查询（通过 ToTraceString 函数获得）直接运行到我的 sql 服务器，则执行计划不包含并行性。

为什么在通过 LINQ 运行 SQL 与 SQL 查询本身时，SQL 的并行性存在差异？

我该如何克服这个问题？我希望我的 LINQ 查询的运行方式与我直接运行其 SQL 时的方式相同。

执行计划示例：

使用 LINQ：

直接SQL：

我可以发布我的 SQL 查询，但我认为它在这里没有帮助...

【问题讨论】：

我遇到了同样的问题 - 从 Web 应用程序运行存储过程导致超时，而直接从 SQL 管理工作室运行它已经足够快了；在那种情况下，重新编译存储过程可以解决它。如果我是你，我会尝试查看已编译的查询 - msdn.microsoft.com/en-us/library/bb896297.aspx（不知道是否有帮助）

尝试运行以下命令DBCC FREEPROCCACHE，然后运行sp_updatestats，看看问题是否仍然存在。

您是否对 DB 运行 SQL Profiler 以查看 Linq 实际执行的 SQL 是什么？另外，客户端使用的连接字符串有什么好笑的吗？

【参考方案1】：

CXPACKET 等待真的有问题吗？

当 SQL Server 收到查询时，它会对其进行优化。如果查询的估计成本大于并行的成本阈值，它将考虑并行查询。如果并行化的查询过多，则始终可以提高此阈值。

我想知道实体框架查询和您的查询之间是否存在任何可能推高估计成本的差异。

无论哪种方式，CXPATCKET 等待都不是问题。它们是任何并行查询的自然组成部分，我们不会为具有多线程的四核服务器支付额外费用，因此我们可以以一系列方式运行所有内容。要检查的另一件事是网络。

通过网络流式传输 IO 时，如果您要返回一堆结果，这可能需要更多时间。这就是为什么在 SQL Server Management Studio 中运行查询可以快速返回，但从另一台服务器查询可能需要一段时间。