我在使用 LINQ To Entities 时遇到问题。
如果我运行我的 LINQ 查询，那么它会在执行计划中使用并行（收集流和修复流），这会导致大量 CXPACKET 等待。
但是，如果我将 LINQ 翻译查询（我通过 ToTraceString 函数获得）直接运行到我的 sql 服务器，则执行计划不包含并行性。
为什么通过 LINQ 运行 SQL 与 SQL 查询本身时，SQL 的并行性存在差异？
我该如何克服这个问题？我希望我的 LINQ 查询的运行方式与我直接运行其 SQL 时的方式相同。
执行计划示例：
使用 LINQ：
直接SQL：
我可以发布我的 SQL 查询，但我认为它在这里没有帮助......
CXPACKET 等待实际上是一个问题吗？
当 SQL Server 收到查询时，它会对其进行优化。如果查询的估计成本大于并行的成本阈值，它将考虑并行查询。如果并行化的查询过多，则始终可以提高此阈值。
我想知道实体框架查询和您的查询之间是否存在任何可能推高估计成本的差异。
无论哪种方式，CXPATCKET 等待都不是问题。它们是任何并行查询的自然组成部分，我们不会为具有多线程的四核服务器支付额外费用，因此我们可以串联运行所有内容。要检查的另一件事是网络。
通过网络流式传输 IO 时，如果您返回一堆结果，这可能需要更多时间。这就是为什么在 SQL Server Management Studio 中运行查询可以快速返回，但从另一台服务器查询可能需要一段时间。