Question

我有一个由EF 6生成的搜索查询有时导致搜索条件出现性能问题，从而产生大量结果。查询性能是不可预测的，有时它表现良好，有时它不是。以下是sql profiler中捕获的查询，它查询视图

exec sp_executesql N'SELECT 
[Extent1].[LastName] AS [LastName], 
[Extent1].[FirstName] AS [FirstName],
.
. 
FROM (SELECT 
[PersonView].[LastName] AS [LastName], 
[PersonView].[FirstName] AS [FirstName],
.
.
FROM [Staff].[PersonView] AS [PersonView]) AS [Extent1]
WHERE [Extent1].[FirstName] = @p__linq__0',N'@p__linq__0  varchar(8000)',@p__linq__0='smith'

以下是存储库代码

public IEnumerable<PersonSearchResult> SearchPersons(Expression<Func<PersonView, bool>> searchCriteria)
{
    var query = _entities.PersonViews.AsExpandable().Where(searchCriteria);
    return query;
}

我正在使用谓词构建器来创建动态搜索条件。

我关注的是使用相同搜索条件的效果的不可预测性。

以下是我的问题

我相信从表格查询格式中选择x的选择x会导致此问题。当我只执行Select的内部部分时，当整个查询都在挣扎时，它表现得更好。这需要调整吗？如果是，从哪里开始？
或者这是数据库的问题吗？因为此查询有时表现良好？

Answer 1

没有
根据WHERE部分中的实际条件集，SQL Server可能会使用索引，这将导致更好的性能（假设有任何更好）。通过非索引列进行过滤是缓慢且耗费资源的，但最糟糕的是 - 它是不可预测的慢速，即今天可以容忍并且明天停止。

通常，具有冗长文本的列（例如人名）很少被编入索引，因此您的特定示例注定表现不佳。当然，除非使用名/姓进行搜索是系统功能的关键部分，否则您将为搜索条件中可能提到的所有列创建索引，包括与这些列一样大的索引。

我建议搜索显示“建议索引”的SQL脚本，应该很方便。

需要EF生成的查询性能调优。还是数据库问题？

1 个答案: