如何在Entity Framework Core中实现Keyset分页？现有Offset分页改造遇阻求助

我明白你遇到的问题了——你尝试把Offset分页改成微软文档推荐的Keyset分页，但因为固定了起始日期，导致每次都返回同一页数据。咱们一步步来解决这个问题：

首先，先说说你当前代码的核心问题：你硬编码了lastDate = new DateTime(2020, 1, 1)，这意味着每次查询都是从这个固定日期之后取前10条数据，自然每次返回的都是第一页。Keyset分页的核心逻辑是用上一页最后一条记录的唯一标记作为下一页的查询起点，而不是用固定值或者页码计算偏移量。

接下来，咱们改造你的代码，实现正确的Keyset分页：

第一步：调整接口参数与查询逻辑 #

不再依赖页码，而是接收上一页最后一条记录的RequestDate和Id（因为可能存在多个记录同一时间创建的情况，Id作为唯一键可以避免漏数据或重复）：

[HttpGet] 
public async Task<ActionResult<RequestResponse>> GetRequest(
    int pageSize = 10, 
    DateTime? lastRequestDate = null, 
    int? lastRequestId = null) 
{ 
    // 构建带唯一排序的查询：先按RequestDate降序，再按Id降序（确保分页的唯一性）
    var query = _context.Request
        .OrderByDescending(x => x.RequestDate)
        .ThenByDescending(x => x.Id);

    // 如果有上一页的标记，就从该标记之后过滤数据
    if (lastRequestDate.HasValue && lastRequestId.HasValue)
    {
        // 逻辑：找RequestDate小于上一页最后日期的，
        // 或者日期相同但Id更小的（因为是降序，更小的Id排在后面）
        query = query.Where(x => x.RequestDate < lastRequestDate.Value 
                                 || (x.RequestDate == lastRequestDate.Value && x.Id < lastRequestId.Value));
    }

    // 取当前页的数据
    var requests = await query.Take(pageSize).ToListAsync();

    // 准备下一页的标记（如果当前页取满了，说明还有下一页）
    DateTime? nextLastDate = null;
    int? nextLastId = null;
    if (requests.Count == pageSize)
    {
        var lastItem = requests.Last();
        nextLastDate = lastItem.RequestDate;
        nextLastId = lastItem.Id;
    }

    // 关于总页数：如果业务必须要，这里保留，但注意CountAsync会扫描全表（性能瓶颈）
    // 建议如果不是必须，去掉总页数，或者用数据库近似计数优化
    var totalCount = await _context.Request.CountAsync();
    var totalPages = (int)Math.Ceiling(totalCount / (double)pageSize);

    // 构造响应，带上下一页需要的标记
    var response = new RequestResponse 
    { 
        Requests = requests, 
        NextLastRequestDate = nextLastDate,
        NextLastRequestId = nextLastId,
        TotalPages = totalPages,
        PageSize = pageSize
    }; 

    return Ok(response); 
}

第二步：理解改造的关键要点 #

1. 动态起始标记：不再用固定日期，而是让前端传递上一页最后一条的RequestDate和Id，这样每次下一页查询都能精准定位到上一页的结束位置。
2. 唯一排序：加上ThenByDescending(x => x.Id)是为了处理同一时间创建的多条记录，避免出现分页重复或遗漏的情况——因为RequestDate可能重复，但Id是唯一的。
3. 性能提升：对比原来的Skip，这种Where过滤的方式可以利用RequestDate和Id的联合索引，直接定位到数据位置，不会随着分页深入而变慢（原来的Skip会让数据库扫描前面所有的行，页码越大越慢）。

第三步：前端调用逻辑调整 #

• 第一次请求：不需要传lastRequestDate和lastRequestId，直接获取第一页数据。
• 后续请求：用响应里的NextLastRequestDate和NextLastRequestId作为参数，就能获取下一页数据。
• 如果NextLastRequestDate为null，说明已经到最后一页了。

关于总页数的优化 #

原来的Count()是你之前实现的性能瓶颈之一，因为它会扫描全表。如果业务不是必须展示总页数，建议直接去掉这部分逻辑，这样整个查询的性能会大幅提升。如果必须要总页数，可以考虑：

• 用数据库的近似计数（比如SQL Server的sys.dm_db_partition_stats），牺牲一点准确性换取性能。
• 单独提供一个接口获取总数量，不要和分页查询放在一起。

这样改造后，你的分页就不会再返回重复页面，同时解决了原来Offset分页的性能问题。

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