KeySet分页比Skip()+Take()快，因其用排序字段值过滤（如WHERE Id > @lastId）避免数据库全表扫描，而后者生成OFFSET需跳过前N行；要求排序字段有覆盖索引、单调无重复，适用于后台列表等场景，不支持任意页跳转。
KeySet分页为什么比 Skip()+Take() 快得多
因为 Skip(10000).Take(20) 会让 EF Core 生成 OFFSET 10000 ROWS，而数据库必须扫描并跳过前 10000 行——哪怕只取 20 条。KeySet 分页不依赖行号，而是用排序字段的值做条件过滤，比如 WHERE Id > @lastId ORDER BY Id LIMIT 20，数据库能直接走索引定位，避免全扫描。
关键前提是：排序字段必须有**覆盖索引**（例如 CREATE INDEX IX_Users_Id ON Users (Id)），且该字段在查询中是**单调递增/递减、无重复**的（如自增主键或带唯一约束的时间戳）。
- 适用场景：后台列表、无限滚动、API 分页接口（尤其是页码靠后或总记录数超百万）
- 不适用场景：需要跳转任意页码（如输入“第 842 页”）、排序字段含大量重复值（如按 Status 分页）
- 注意：必须保证客户端传回上一页最后一条记录的排序字段值（如
lastId），不能只传页码
怎么写一个安全的 KeySet 分页查询（EF Core）
核心是把 Skip() 换成 Where() + 显式参数，再配合 AsNoTracking()：
var lastId = 12345; // 上一页最后一条的 Id var pageSize = 20; <p>var nextBatch = await context.Users .AsNoTracking() .Where(u => u.Id > lastId) // 关键：用值过滤，不是跳行 .OrderBy(u => u.Id) .Take(pageSize) .ToListAsync();</p>
如果要支持「上一页」，就改成 u.Id 并倒序查（OrderByDescending），再反转结果；或者统一用正序 + TakeLast()（EF Core 8+ 支持）。
- 必须加
AsNoTracking()：分页只读，不跟踪实体可省掉变更追踪开销，实测快 30%~50% - 不能漏
OrderBy：没明确排序，数据库返回顺序不确定，KeySet 就会错乱 - 参数必须用变量（而非字面量），否则 EF 可能无法参数化，引发 SQL 注入或执行计划缓存失效
MySQL / PostgreSQL 怎么手写 KeySet 分页 SQL
绕过 EF 直接发 SQL 更可控，尤其当排序字段是复合字段（如 CreatedAt DESC, Id DESC）时：
-- MySQL 8.0+ SELECT * FROM Users WHERE (CreatedAt, Id) <pre class="brush:php;toolbar:false;">-- PostgreSQL（支持行值比较） SELECT * FROM Users WHERE (CreatedAt, Id) <p>SQL Server 不原生支持行值比较，得拆成 AND 条件：</p><pre class="brush:php;toolbar:false;">-- SQL Server SELECT TOP 20 * FROM Users WHERE CreatedAt
- 注意括号优先级：多个字段比较必须严格按排序方向对齐（升序用 ）
- 所有参与排序的字段都得建联合索引，顺序和
ORDER BY一致，例如IX_Users_CreatedAt_Id - 避免在 WHERE 中用函数（如
DATE(CreatedAt)），否则索引失效
KeySet 分页容易踩的三个坑
最常出问题的地方不在代码，而在数据语义和边界处理：
-
重复排序值没处理：比如按
Status分页，多个用户状态相同，WHERE Status > @lastStatus会漏掉同状态的其他记录。解法：补一个唯一字段（如Id）组成复合条件：WHERE (Status, Id) > (@lastStatus, @lastId) -
客户端传错 last 值：比如上一页最后一条是
Id=100，但前端误传lastId=99，结果跳过一条。建议服务端校验：查出第一条的Id，和传入lastId对比，偏差过大则报错 - 数据实时写入干扰分页：分页过程中新记录插入到「中间位置」（如按时间排序，新记录时间落在上一页末尾和本页开头之间），会导致某条记录被跳过或重复。这是 KeySet 的固有限制，无法完全规避，只能接受「最终一致性」或改用游标（cursor）+ 时间窗口兜底
真正难的不是写出 KeySet 查询，而是想清楚你的排序字段是否稳定、客户端能否可靠传递游标值、以及业务能否容忍少量数据偏移。
