skip+limit分页在mongodb中易变慢，因其需扫描并丢弃前n条文档，数据量越大、页码越深，性能线性恶化；应改用游标分页，以排序字段值为起点避免跳过，配合$match前置的聚合优化及压测验证。
为什么 Skip + Limit 在 MongoDB 分页里容易变慢
MongoDB 的 Skip 本质是跳过前 N 条文档再返回结果，不是“直接定位第 N 页”。数据量越大，Skip 越要扫描并丢弃大量文档，CPU 和 I/O 压力直线上升。10 万条数据跳到第 1000 页（Skip(10000)）时，MongoDB 往往比第 1 页慢 5–10 倍，而且这个延迟会随页码线性恶化。
这不是 C# 驱动的问题，是底层查询模型决定的。所以真实项目中，除非数据量极小（Skip/Limit 当默认分页方案。
C# 中用官方驱动写 Skip+Limit 分页的正确姿势
用 MongoClient 获取集合后，调用 Find 返回 IAsyncCursor，再链式调用 Skip 和 Limit —— 注意：必须在 ToListAsync 或 ToListAsync 之前调用，否则无效。
-
Skip和Limit是 LINQ 式扩展方法，需引用MongoDB.Driver.Linq；但更推荐用原生Find+Sort+Skip+Limit链式调用，避免 LINQ 表达式解析开销 - 页码从 0 开始算更安全：
skip = (page - 1) * pageSize容易在 page=0 时出错，直接用skip = pageIndex * pageSize - 务必加
Sort（如按_id或时间字段），否则分页结果可能乱序——MongoDB 不保证自然顺序
var filter = Builders<user>.Filter.Eq(u => u.Status, "active");
var cursor = collection.Find(filter)
.SortBy(u => u.CreatedAt) // 必须有 Sort
.Skip(20) // 跳过前 20 条（第 1 页 size=20）
.Limit(20) // 只取 20 条
.ToListAsync();</user>
什么时候该换游标分页（Cursor-based Pagination）
当用户滚动加载、无限下拉、或页码超过 100 时，Skip 已经不可靠。游标分页用上一页最后一条记录的排序字段值（如 CreatedAt）作为下一页起点，绕过跳过逻辑。
- 适合场景：Feed 流、日志列表、监控告警历史
- 关键点：排序字段必须有唯一性或高区分度，否则可能漏/重数据；推荐组合
{CreatedAt: -1, _id: -1} - C# 实现就是把上一页最后一条的
CreatedAt和_id存下来，下一次查询用lt（小于）条件：filter = Builders<log>.Filter.Lt(l => l.CreatedAt, lastTime) | ...</log> - 不能跳转任意页，但性能稳定，且天然支持实时插入不偏移
聚合管道里用 $skip/$limit 要特别注意什么
在 Aggregate 阶段里用 $skip 和 $limit 看似一样，但实际执行顺序会影响内存和性能。尤其当 $match 放在 $skip 后面，MongoDB 就没法利用索引提前过滤，可能全表扫描后再跳过。
- 永远把
$match放在$skip和$limit之前——这是聚合分页能快的前提 -
$facet可以同时查总数和当前页，但总数量大时$facet会吃很多内存，慎用于 >10w 数据 - C# 驱动中，聚合结果需手动映射：用
Aggregate<tresult>()</tresult>并指定泛型类型，别依赖自动推导
游标分页的健壮性远高于 Skip+Limit，但需要前端配合传上次末尾值；而 Skip+Limit 简单直接，只适合低频、小数据、浅层翻页。真正上线前，一定要用真实数据量压测第 50 页、第 100 页的响应时间——这点最容易被忽略。
