Entity Framework Core分页：Count()获取总条数的效率担忧

你担心dbContext.Things.Count()的效率完全是合理的——当表数据量很大时，这条语句会触发SELECT COUNT(*) FROM Things，如果没有合适的索引支撑，数据库不得不做全表扫描，性能确实会打折扣。下面给你几个针对性的优化方案，你可以根据业务场景选择：

• 用近似值替代精确计数（适合非强实时场景）
  如果业务允许不需要绝对精确的总条数（比如只显示“共1000+条”这种模糊提示），可以利用数据库的系统视图快速获取估算值。以SQL Server为例，sys.dm_db_partition_stats可以直接返回表的行数估算，速度比全表Count快几个数量级：

  var approximateCount = dbContext.Database.SqlQuery<int>(@"
      SELECT SUM(rows) 
      FROM sys.dm_db_partition_stats 
      WHERE object_id = OBJECT_ID('Things') 
      AND index_id < 2 -- 只统计聚集索引/堆表的行数
  ").FirstOrDefault();
  

  注意这个是估算值，和实际行数可能有小误差，但胜在速度极快。

• 给Count()查询加索引支撑（必须精确计数时）
  如果必须要精确的总条数，那一定要确保你的Count查询能用到合适的索引。比如你的分页是带条件的（比如Where(t => t.IsActive)），就给过滤字段（IsActive）建索引，这样数据库会走索引扫描而不是全表扫描。另外，推荐用LongCount()替代Count()，避免数据量过大时的int溢出问题：

  var totalCount = dbContext.Things.Where(t => t.IsActive).LongCount();
  

• 一次查询同时获取分页数据和总条数（减少数据库往返）
  不要分开执行两次查询（一次Count，一次Skip/Take），可以利用SQL的窗口函数COUNT(*) OVER()，让数据库一次返回分页数据和总条数，减少一次数据库请求：

  int pageNumber = 1;
  int pageSize = 10;
  
  var pageDataWithTotal = dbContext.Things
      .Select(t => new 
      {
          Thing = t,
          TotalCount = EF.Functions.Count(t.Id) OVER()
      })
      .Skip((pageNumber - 1) * pageSize)
      .Take(pageSize)
      .ToList();
  
  long totalCount = pageDataWithTotal.FirstOrDefault()?.TotalCount ?? 0;
  var pageThings = pageDataWithTotal.Select(item => item.Thing).ToList();
  

  这种方式只触发一次数据库查询，同时拿到需要的分页数据和总条数，效率比两次查询高很多。

• 缓存总条数（适合数据更新不频繁的场景）
  如果你的表数据不是实时更新的，或者业务允许几分钟的延迟，可以把总条数缓存起来，比如用MemoryCache或者分布式缓存（如Redis），每隔一段时间刷新一次：

  var cacheKey = "Things_Total_Count";
  if (!_memoryCache.TryGetValue(cacheKey, out long totalCount))
  {
      totalCount = dbContext.Things.LongCount();
      _memoryCache.Set(cacheKey, totalCount, TimeSpan.FromMinutes(5));
  }
  

  这种方式能彻底避免频繁的Count查询，性能提升非常明显。

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