C# EF5.0实现服务端分页时Count统计总记录数慢如何优化

现有代码的可直接优化点 #

你当前的实现首先可以做几处低成本改动，立刻降低响应耗时：

• 把同步执行的LongCount()替换为异步的LongCountAsync()，同时将count查询和列表查询改为并行执行，不需要等待count返回后再查询列表数据，总耗时可以从「count耗时+列表耗时」降低为「两者最大值」。
• 确保count查询不会携带无意义的OrderBy逻辑：排序不会影响count结果，反而会让数据库额外执行排序计算，增加开销。你当前的代码顺序是先count再拼接排序，这点没有问题，后续迭代注意不要调整顺序把排序逻辑放到count之前即可。
• 给筛选条件、排序条件涉及的字段建立合适的联合覆盖索引：如果count查询可以直接通过索引完成，不需要回表读取主表数据，执行速度会有数量级提升。
• 简化count查询逻辑：如果列表查询包含多表Join，且关联的表仅用于补充字段、不会改变主表的结果行数，count查询可以去掉不必要的Join，直接统计主表符合条件的行数即可。

优化后的泛型方法参考实现：

public static async Task<(List<T> Items, int TotalCount)> GetFilteredAndTotal<T>(this IQueryable<T> source, FilterContainer filter)
{
    if (filter == null)
    {
        var countTask = source.CountAsync();
        var listTask = source.ToListAsync();
        await Task.WhenAll(countTask, listTask);
        return (listTask.Result, countTask.Result);
    }

    // 先拼接所有查询共用的过滤条件
    if (filter.Where != null)
    {
        source = source.Where(filter.Where);
    }

    // 构造count查询，不带排序、分页
    var countTask = source.LongCountAsync();

    // 构造列表查询，拼接排序、分页
    if (filter.OrderBy != null)
    {
        source = source.OrderBy(filter.OrderBy);
    }
    if (filter.Take != -1)
    {
        source = source.Skip(filter.Skip).Take(filter.Take);
    }
    var listTask = source.ToListAsync();

    await Task.WhenAll(countTask, listTask);
    return (listTask.Result, (int)countTask.Result);
}

注：用ValueTuple替代旧版Tuple可以提升代码可读性，不需要修改原有业务逻辑即可兼容。

替代传统精确count分页的方案 #

如果做完上述优化后count性能依然达不到要求，可以根据业务场景选择以下方案，完全规避高频count查询的开销：

• 缓存总数值
  相同筛选条件下的count结果不会随翻页变化，你可以将筛选条件序列化为缓存Key，把第一次查询得到的count结果缓存30秒到5分钟，后续相同筛选条件的翻页请求直接读缓存即可。对绝大多数业务场景来说，总条数短时间内的微小误差完全可以接受，不会影响用户体验。
• 游标分页（Keyset Pagination）
  针对不需要跳转到指定页码、不需要展示总页数的场景（比如信息流、评论列表、无限滚动页面），可以完全废弃count逻辑，改用游标分页：每次请求时携带上一页最后一条数据的定位标识（通常是排序字段+主键的组合值），查询时直接通过条件过滤取指定条数的数据，同时多取1条用来判断是否存在下一页。这种方式不管数据量多大都能保持毫秒级响应，性能远高于传统Skip/Take分页，缺点是不支持跳页操作。
• 非精确总数展示
  针对搜索结果、内容列表这类不需要100%精确总数的场景，可以直接用数据库的统计估算值（比如MySQL的information_schema.tables统计值、PostgreSQL的pg_class.reltuples），毫秒级即可返回结果，误差通常在5%以内，普通用户完全感知不到。也可以设置阈值，比如总数超过10000条时直接展示「10000+」，不需要统计真实值——绝大多数用户不会翻到10页之后，没必要为了极低概率的深翻页请求消耗数据库性能。
• 总数异步加载
  首屏请求只返回第一页列表数据，不携带总数字段，等前端把列表渲染完成后，再单独发异步请求拉取总数。这种方式可以让用户第一时间看到内容，不会因为count查询慢导致整个页面加载等待，大幅降低用户感知的加载时长。

避坑提醒 #

• 绝对不要把全量数据拉到应用内存中再做count和分页，这种方式的性能比数据库直接查询低两个数量级以上，数据量稍大就会导致服务内存溢出。
• 尽量限制分页深度，比如禁止用户查询超过100页之后的数据，深分页本身的Skip/Take性能也会随偏移量增大急剧下降，结合游标分页使用体验更好。

内容的提问来源于stack exchange，提问作者FloMaster