7

我在我的数据访问层上使用实体框架 5、ObjectContext 和 POCO。我有一个通用的存储库实现，并且我有一个使用 Skip() 和 Take() 通过分页查询数据库的方法。一切正常，除了跳过很多行时查询性能非常慢（我说的是 170k 行）

这是我对 Linq to Entities 的查询的摘录：

C#代码：

ObjectContext oc = TheOBJEntitiesFactory.CreateOBJEntitiesContext(connection);
var idPred = oc.CreateObjectSet<view_Trans>("view_Trans").AsQueryable();
idPred = idPred.OrderBy(sortColumn, sortDirection.ToLower().Equals("desc"));
var result = idPred.Skip(iDisplayStart).Take(iDisplayLength);
return new PagedResult<view_Trans>(result, totalRecords);

在 Transact-SQL 的翻译查询中，我注意到不是直接将ROW_NUMBER()子句与视图一起使用，而是直接进行子查询并将ROW_NUMBER()应用于子查询的结果......

例子：

select top(10) extent1.A, extent1.B.extent1.C from (
select extent1.A, extent1.B, extent1.C, 
row_number() OVER (ORDER BY [Extent1].[A] DESC) AS [row_number] 
from (
select A,B,C from table as extent1)) as extent1
WHERE [Extent1].[row_number] > 176610
ORDER BY [Extent1].[A] DESC

这大约需要 165 秒才能完成。关于如何提高翻译查询语句的性能的任何想法？

4

2 回答 2

2

对于那些不遵循上述评论的人，我怀疑问题不在于 extra SELECT，因为这个 extraSELECT存在于许多不需要 165 秒运行的 EF 查询中。我最终注意到他的 ObjectSet 引用了 aVIEW并想知道这是否可能是问题的一部分。经过一些实验，他将问题缩小到LEFT JOIN内部视图。我建议他对那个查询运行数据库优化顾问；他做到了，并且建议的两个指数解决了这个问题。

于 2013-05-08T20:18:17.193 回答
1

缓慢的一个原因可能是您的 sql 对您的行进行了两次排序。

要控制查询，我知道的唯一选项是调用 idPred.SqlQuery("Select ...", params)。这将允许您为数据请求编写自己的优化查询。

于 2013-05-07T08:39:04.277 回答