实体框架分页性能注意事项

Question

我对Entity Framework 6中的复杂查询相当熟悉，所以我有一个与分页相关的问题。

场景如下：我有一个项目，我以自己的形式描述了数据模型并使用T4模板，它生成了适当的实体，高保真变更跟踪伴侣实体，一个复杂的动态搜索查询实体，用于询问有关相关模型的问题（例如，entity.SearchNameCriterium =“t”; entity.SearchNameType = StringSearchType.StartsWith，围绕此构建的UI将为用户提供强大的搜索工具。）

在这里，我有一个部分，其中使用分页来下拉组成元素列表： 当我使用插入按钮插入一些东西时，如果这会溢出到下一页（每次都是'x'个项目，在常量中定义 - 我稍后将其移动到一个设置）我使用以下代码：

this.context.SaveChanges();
int offset = searchCurItemLstCriteriaSkip - 1;
var queryBase = this.queryCurItemLstFormContainer;
int idFind = newDataContext.Identifier;
while (queryBase.Any())
{
    queryBase = queryCurItemLstFormContainer.Skip((++offset) * searchCriteriaCount).Take(searchCriteriaCount);
    if (queryBase.Any(k => k.Identifier == idFind))
    {
        this.searchCurItemLstCriteriaSkip = offset * searchCriteriaCount;
        break;
    }
}

基本原理是该项目将始终在当前页面的DB内或当前页面之后的某个点输入，因此理论上您可以从当前页面开始并继续前进。

我只想知道是否有更好的方法来实现这一目标，或者这种方法是否有效......？如果有人想知道：组合框用于选择当前项目，因为列表只会浪费空间，您一次只需要一个项目，搜索功能在ComboBox的下拉列表中也能正常工作。与此关联的UI元素是通过文本模板生成的XAML。

我只是想确定我了解移动到最新页面的查询可能对非常大的数据库产生的影响。

进行查询有哪些性能考虑因素。选择（k =＆gt; k.Identifier）.Count（）/ itemsPerPage？在这种情况下会更快吗？

洞察力不仅仅是欢迎。

Answer 1

基于此重点，在查询上使用Count（），并将选择限制为标识符：使用Count功能可以快几个数量级。

这背后的基本原理是：如果你正在分页并使用迭代方法，如果有10,000条记录，每页25条，则至少800条查询（400条用于检查是否有更多项目，400条用于检查命中数据库，而Count只有一个。

即使Count可以被视为潜在的昂贵操作，但是在最初声明的方法中对数据库的所有查询之间的延迟大于单个Count请求。有时最简单的解决方案是最好的。