skip() 在大数据量下变慢是因为 MongoDB 需扫描跳过前 N 条文档，N 越大成本越高；即使索引覆盖也无法避免游标底层全扫，翻页越深响应越慢，且 allow_disk_use=True 无加速作用。
为什么 skip() 在大数据量下会变慢？
因为 skip() 本质是让 MongoDB 扫描并跳过前 N 条文档，N 越大，扫描成本越高。当 skip(100000) 时，即使只取 20 条，它仍要定位到第 100001 条——这和索引是否覆盖无关，是游标底层行为。
真实场景中，用户翻到第 5000 页（每页 20 条 → skip(99980)），响应可能从毫秒级升至秒级，甚至触发慢查询告警。
- 除非数据集极小（skip() 做分页
-
skip()无法利用复合索引跳过扫描，即使{created_at: 1, _id: 1}已建好 - 聚合管道里
$skip同样有此问题，不解决根本瓶颈
用游标式分页（Cursor-based Pagination）替代 skip()
核心思路：不依赖“第几页”，而是记住“上一页最后一条的排序键值”，下一页从该值之后开始查。这要求排序字段绝对唯一、可比较、有索引。
最稳妥的是用 _id（ObjectId 默认单调递增），或组合 {updated_at: 1, _id: 1} 防止时间重复。
立即学习“Python免费学习笔记（深入）”；
- 首次请求：
collection.find({}).sort({'_id': 1}).limit(20)，拿到第 20 条的_id（记为last_id） - 下一页请求：
collection.find({'_id': {'$gt': last_id}}).sort({'_id': 1}).limit(20) - 必须确保排序字段有索引，否则
$gt查询会全表扫 - 反向翻页（上一页）需用
$lt+ 降序，逻辑稍复杂，但仍是 O(1) 索引查找
Python 实现时容易漏掉的三个细节
PyMongo 的游标本身不保存状态，每次查询都是新上下文。所谓“游标分页”，实际是靠业务层维护分页锚点（如 last_id），不是 MongoDB 游标对象自带功能。
- 不要试图复用同一个
cursor对象多次调用next()实现分页——它只适用于单次遍历，无法跨请求保持位置 - HTTP 接口返回时，必须把锚点（如
last_id）转成字符串（str(doc['_id'])），因为 ObjectId 不能直接 JSON 序列化 - 客户端传回的锚点要严格校验：用
ObjectId.is_valid()判断格式，再用ObjectId()构造，避免注入或类型错误导致空结果
什么时候还是得用 skip()？
仅限两类场景：一是管理后台需要跳转任意页码（如输入“第 127 页”），且数据量可控；二是做一次性导出，对性能不敏感。
若必须用，务必加硬限制：比如最大只允许 skip(10000)，超出则报错或自动降级为游标分页 + 提示“请用下一页”。
- 在
find()前加explain()测试执行计划，确认executionStats.nReturned和executionTimeMillis是否随 skip 值线性增长 - 监控 slowms 日志，重点抓
command中含skip且耗时 > 100ms 的请求 - 注意 PyMongo 4.0+ 的
allow_disk_use=True对skip()无加速作用，别被误导
