C#怎么实现分页查询_C# EF Core分页和排序查询教程【实战】-C#.Net教程-PHP中文网

ef core 分页不能只靠 skip + take，因数据库需扫描前 n 行导致性能骤降；应优先用游标分页、避免 count(*)、确保排序字段有覆盖索引并禁用客户端求值。

c#怎么实现分页查询_c# ef core分页和排序查询教程【实战】

EF Core 分页不能只靠 Skip + Take，否则查大表会越来越慢，甚至超时。

为什么 `Skip` + `Take` 在大数据量下很危险

SQL Server 或 PostgreSQL 执行 OFFSET 10000 ROWS FETCH NEXT 20 ROWS ONLY 时，数据库仍需扫描前 10000 行；MySQL 8.0+ 虽有优化，但 LIMIT 10000, 20 同样走全索引扫描。数据量过万后，响应时间从毫秒级跳到秒级，用户刷新一次页面卡住几秒是常态。

常见错误现象：TaskCanceledException、HTTP 504、SQL 查询执行计划里出现“Index Scan”而非“Index Seek”。

仅适用于总记录数
必须配合 OrderBy（否则 EF Core 会报错）
无法跳转到指定页码（比如直接点“第 200 页”），因为要先算出前 199 × pagesize 条

用游标分页（Cursor-based Pagination）替代页码分页

核心思路：不依赖“第几页”，而是记住“上一页最后一条的排序字段值”，下一页查询就从这个值之后开始取。适合按时间、ID 等单调递增字段排序的场景（如订单列表、日志流）。

实操建议：

排序字段必须有索引，且**不允许为空**（NOT NULL）
推荐组合主键或唯一索引（如 (CreatedAt DESC, Id DESC)），避免同值冲突
查询语句形如：WHERE CreatedAt
EF Core 中不用 Skip，改用 Where + 参数化条件，再 Take(21)（多取 1 条用于判断是否有下一页）

示例（获取下一页订单）：

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

var nextOrders = await context.Orders
    .Where(o => o.CreatedAt  o.CreatedAt)
    .ThenByDescending(o => o.Id)
    .Take(21)
    .ToListAsync();

需要显示总页数？先评估是否真有必要

前端显示“共 1234 页”看似友好，实则代价高昂：每次分页都得执行 COUNT(*)，在高并发下成为数据库瓶颈。很多产品已转向“无限滚动”或“加载更多”按钮，彻底规避总数计算。

如果业务强依赖总数（如导出页数预估、权限校验），可考虑：

缓存总数：用 Redis 存 orders:count，写操作时异步更新（注意最终一致性）
估算总数：对大表用 SELECT reltuples::BIGINT AS estimate FROM pg_class WHERE relname='orders'（PostgreSQL）
分页接口返回 hasNext 布尔值，而不是 totalPages —— 用户真正需要的是“还能不能往下翻”，不是精确页码

排序字段含中文或复杂表达式怎么办

EF Core 对 OrderBy 中的字符串比较默认使用数据库 collation，但若涉及 .ToUpper()、.Substring() 或自定义函数，可能触发客户端求值（Client Evaluation），导致整张表拉到内存排序 —— 这比 Skip 更糟。

排查方法：启用 EF Core 日志，看生成的 SQL 是否含 ORDER BY；若日志里出现 Microsoft.EntityFrameworkCore.Query: Warning: The LINQ expression could not be translated，说明已降级为客户端排序。