EntityFramework 分页问题探讨之 OrderBy

应用场景

最近被应用程序中页面加载慢的问题所折磨，看似容易的问题，其实并不容易（已经持续两天时间了），经过“侦查”，发现了两个“嫌疑犯”：

1. EntityFramework 生成执行的 SQL
2. 数据库中索引创建

在《程序员眼中的 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 条件就是这样用的，那就是排序字段类型的问题，关于这个问题，经过反复测试，也没有好的方式解决，我就网上搜了下，对我有所帮助的资源有下面三个：

1. EF orderby / thenby combo extension method
2. Help me understand “LINQ to Entities only supports casting Entity Data Model primitive types”
3. 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 关键字（分页产生的页码数量），然后又对数据库中的索引进行了调整，页面加载慢的问题终于得到了一定解决。

看似改一点代码的问题，却花了这么长时间，结果很简单，过程却很复杂，就记录到这。