EF 永远生成此查询

Question

我有一个父子表关系。在存储库中，我正在这样做：

return (from p in _ctx.Parents  
.Include( "Children" )  
select p).AsQueryable<Parent>();  

然后在过滤器中，我想通过子 ID 列表过滤父级：

IQueryable<Parent> qry;  // from above
List<int> ids;  // huge list (8500)
var filtered =
from p in qry.Where( p => p.Children.Any(c => ids.Contains(c.ChildId)) ) select s;  

我的 id 列表非常庞大。这会生成一个简单的 SQL 语句，它确实有一个巨大的 id 列表“in (1,2,3...)”，但它自己运行并不需要太多时间。然而，EF 只需要一整分钟来生成语句。我通过设置断点并调用来证明这一点：

((ObjectQuery<Parent>)filtered).ToTraceString();

这需要所有时间。问题出在我最后的 linq 语句中吗？我不知道在（ids）中做相当于 Child.ChildId 的任何其他方法。即使我的 linq 语句很糟糕，这到底怎么会花这么长时间？

Answer 1

不幸的是，在 Linq to Entities 中构建查询是一个很大的打击，但我发现它通常可以节省时间，因为它能够在实际访问数据库之前从它们的组件中构建查询。

他们实现 Contains 方法的方式很可能使用了一种假设 Contains 通常用于相对较小的数据集的算法。根据我的测试，列表中每个 ID 所花费的时间在 8000 左右开始飙升。

因此，将您的查询分解成碎片可能会有所帮助。将它们分成 1000 或更少的组，并连接一堆 Where 表达式。

var idGroups = ids.GroupBy(i => i / 1000);
var q = Parents.Include("Children").AsQueryable();
var newQ = idGroups.Aggregate(q, 
    (s, g) => s.Concat(
                  q.Where(w => w.Children.Any(wi => g.Contains(wi.ChildId)))));

这大大加快了速度，但对于您的目的可能还不够，在这种情况下，您将不得不求助于存储过程。不幸的是，这个特定的用例不适合预期的实体框架行为的“盒子”。如果您的 id 列表可以作为来自同一实体上下文的查询开始，那么实体框架将可以正常工作。

Answer 2

用 Lambda 语法重新编写您的查询，它会将时间缩短多达 3 秒（或者至少对我的 EF 项目来说是这样）。

return _ctx.Parents.Include( "Children" ).AsQueryable<Parent>();  

和

IQueryable<Parent> qry;  // from above
List<int> ids;  // huge list (8500)
var filtered = qry.Where( p => p.Children.Any(c => ids.Contains(c.ChildId)) );