应用场景
最近被应用程序中页面加载慢的问题所折磨,看似容易的问题,其实并不容易(已经持续两天时间了),经过“侦查”,发现了两个“嫌疑犯”:
- EntityFramework 生成执行的 SQL
- 数据库中索引创建
在《程序员眼中的 SQL Server-非聚集索引能给我们带来什么?》这一篇博文中,我把怀疑对象放在了数据库索引上,其实索引只是一方面的问题,最后通过仔细观察 EntityFramework 生成执行的 SQL 代码(EntityFramework 中如何查看执行 SQL?),主要查看的是获取分页列表的 SQL,最后发现,在分页列表获取的时候,执行的 SQL 是所有条件,并没有分页,也没有 OrderBy,这是个奇怪的问题,因为结果是分页的,但是在数据库执行的 SQL 代码,却是获取所有列表,我们来看一下,这是个什么情况???
上面所说的有点乱,我再重述下应用场景:我们使用 EntityFramework 做分页查询,一般一行代码就可以搞定(Linq 的强大),比如:
var list = query.where(...).OrderByDescending(...).Skip(...).Take(...).ToList();
对,你没看错,就是这么简单,这也是我们一般所使用的方法,在一般应用中可能不会出现什么问题,但是当数据量非常大的时候,而且你的代码经过不断的改写,这时候可能就有些问题了,在我现在的应用项目中,主要是 OrderByDescending 这个排序没有在 SQL 执行,因为这个原因,还导致后面的分页没有执行,但是运行的结果是分页的,查看到的执行 SQL 是获取所有 where 条件下的列表,也就是说分页并不是在数据库中执行的,而是获取到内存中,然后再进行的分页,这导致两个问题,一个就是内存飙升(获取列表数很大的情况),还有一个当然是页面访问慢。
问题分析
为了方面大家理解,我先贴一下现在应用程序中分页部分的代码:
protected override IEnumerable<TAggregateRoot> FindAll(ISpecification<TAggregateRoot> specification, System.Linq.Expressions.Expression<Func<TAggregateRoot, dynamic>> sortPredicate, SortOrder sortOrder, int pageNumber, int pageSize)
{
if (pageNumber <= 0)
throw new ArgumentOutOfRangeException("pageNumber", pageNumber, "The pageNumber is one-based and should be larger than zero.");
if (pageSize <= 0)
throw new ArgumentOutOfRangeException("pageSize", pageSize, "The pageSize is one-based and should be larger than zero.");
var query = efContext.Context.Set<TAggregateRoot>()
.Where(specification.GetExpression());
int skip = (pageNumber - 1) * pageSize;
int take = pageSize;
if (sortPredicate != null)
{
switch (sortOrder)
{
case SortOrder.Ascending:
return query.OrderBy(sortPredicate.Compile()).Skip(skip).Take(take).ToList();
case SortOrder.Descending:
return query.OrderByDescending(sortPredicate.Compile()).Skip(skip).Take(take).ToList();
default:
break;
}
}
return query.Skip(skip).Take(take).ToList();
}
你能看出什么问题吗?看似没什么问题,执行后就会出现上面我所描述的那个问题,我原来以为是 Where 和 OrderBy 顺序的问题,现在看来还蛮可笑的,后来把中间查询的代码修改了下,进行测试:
var query = efContext.Context.Set<TAggregateRoot>()
.Where(specification.GetExpression()).OrderBy(p=>p.ID).Skip(skip).Take(take);
OrderBy 没有使用参数传过来的 lambda 表达式,而是用聚合根的 ID 进行排序,通过查看生成的 SQL,是正确的分页代码,也就是说问题出在 sortPredicate 参数,或者说是 Expression<Func<TAggregateRoot, dynamic>>
的参数类型上面,EntityFramework(准确的说应该是是 Linq)中 OrderBy 方法的参数类型是 Expression<Func<TSource, TKey>>
,TSource 表示数据源类型,TKey 表示返回值类型(注意委托类型为 Func),比如这个参数: p=>p.ID,就表示数据源类型为 TAggregateRoot,返回值类型为 int,执行排序就是 ID 字段。
因为我们数据源类型使用的是 TAggregateRoot,在排序字段类型指定方面,我们没办法具体的指定(比如 p=>p.Name 等),因为 TAggregateRoot 类型中只有一个 ID 属性,所以我们必须通过表达式进行传递,也就是参数 sortPredicate,可以看到数据源类型为 TAggregateRoot,返回值类型(或者称为排序字段类型)为 dynamic,这个表示动态编译类型,没怎么了解过,只是知道大体意思。数据源类型没什么问题,因为我们 where 条件就是这样用的,那就是排序字段类型的问题,关于这个问题,经过反复测试,也没有好的方式解决,我就网上搜了下,对我有所帮助的资源有下面三个:
- EF orderby / thenby combo extension method
- Help me understand “LINQ to Entities only supports casting Entity Data Model primitive types”
- c# 扩展方法 奇思妙用 高级篇 九:OrderBy(string propertyName, bool desc)
还有一个被我关掉找不到了,大概意思是和第二个一样的,都是用范型指定排序类型,第三个是园友写的,很不错,我原来以为看到希望了,但是发现和我的应用场景不太一样,比如:var orderedQueryable = Queryable.OrderBy(repository, (dynamic)keySelector); 这段代码中的 repository 就不知其意思,我最后采用的方式是用范型指定排序类型,经过测试是可以的,代码如下:
protected override IEnumerable<TAggregateRoot> DoFindAll<TOrderSort>(ISpecification<TAggregateRoot> specification, System.Linq.Expressions.Expression<Func<TAggregateRoot, TOrderSort>> sortPredicate, SortOrder sortOrder, int pageNumber, int pageSize)
{
if (pageNumber <= 0)
throw new ArgumentOutOfRangeException("pageNumber", pageNumber, "The pageNumber is one-based and should be larger than zero.");
if (pageSize <= 0)
throw new ArgumentOutOfRangeException("pageSize", pageSize, "The pageSize is one-based and should be larger than zero.");
var query = efContext.Context.Set<TAggregateRoot>()
.Where(specification.GetExpression());
int skip = (pageNumber - 1) * pageSize;
int take = pageSize;
if (sortPredicate != null)
{
switch (sortOrder)
{
case SortOrder.Ascending:
return query.OrderBy(sortPredicate).Skip(skip).Take(take).ToList();
case SortOrder.Descending:
return query.OrderByDescending(sortPredicate).Skip(skip).Take(take).ToList();
default:
break;
}
}
return query.Skip(skip).Take(take).ToList();
}
代码改过之后,通过 Sql Server Profiler 在数据库中跟踪 SQL 执行,终于发现了 Top 关键字(分页产生的页码数量),然后又对数据库中的索引进行了调整,页面加载慢的问题终于得到了一定解决。
看似改一点代码的问题,却花了这么长时间,结果很简单,过程却很复杂,就记录到这。