“Index Skip”并非MongoDB真实功能，而是误解；索引无法加速skip()，因其仍需从排序结果开头逐条扫描跳过N条；真正高效的是游标分页，依赖单调唯一字段（如_id）配合范围查询（$gt/$lt）与匹配索引实现零扫描分页。
什么是“Index Skip”？它并不存在
MongoDB 没有叫 Index Skip 的功能或优化机制。这是个常见误解——很多人听到“用索引跳过”就以为数据库能像数组下标一样直接定位到第 N 条，从而绕过 skip() 的性能问题。但事实是：skip() 无论有没有索引，都必须从排序结果的开头逐条计数跳过；索引只能加速排序和过滤，不能让 skip() “跳得更快”。官方文档明确说：cursor.skip() requires the server to scan from the beginning of the input results set。
为什么加了索引，skip 还是慢？
关键在执行路径：索引帮你快速拿到“所有匹配文档 + 排好序的结果集”，但 skip(N) 仍要在这个已排序的结果集上从头数 N 条再开始返回。N 越大，扫描量越大，I/O 和 CPU 开销越明显。
- 即使
{createdAt: -1}有索引，skip(50000)仍需遍历前 5 万条已排序文档（哪怕只是读取 _id） - 聚合管道里的
$skip同样无效——它发生在内存中，且无法利用索引提前裁剪 - 复合索引如
{status: 1, createdAt: -1}可加速find({status: "active"}).sort({createdAt: -1})，但后续skip(1000)还是线性扫描
真正能替代 skip 的，是游标分页（Cursor-based Pagination）
不是“用索引跳过”，而是“用索引定位起始点”。核心是把“我要第 100 页”转化成“从这条记录之后取 20 条”。这才能彻底规避 skip() 的扫描开销。
- 必须依赖一个**单调、唯一、有索引**的字段，最常用的是
_id（ObjectId 天然递增）或createdAt（需确保写入时严格单调，或加_id复合去重） - 首次查询：不带游标，固定排序，例如
db.logs.find().sort({_id: 1}).limit(20) - 取响应中最后一条的
_id值，比如ObjectId("65a1b2c3d4e5f67890123456") - 下一页查询：改用范围条件
db.logs.find({_id: {$gt: ObjectId("65a1b2c3d4e5f67890123456")}}).sort({_id: 1}).limit(20) - 升序用
$gt，降序用$lt；若排序字段可能重复（如createdAt），必须复合_id防漏/重：{createdAt: {$gt: ISODate("...")}, _id: {$gt: ObjectId("...")}}
索引设计必须匹配游标查询模式
游标分页的性能，最终卡在索引是否能支撑 range + sort 一步到位。如果索引没对齐，就会退化成 IXSCAN → SORT → LIMIT，甚至触发内存排序（DEFAULT_SORTER）。
- 单字段游标（如只用
_id）：默认已有_id索引，无需额外建索引 - 时间戳游标（如
createdAt）：必须显式建索引db.collection.createIndex({createdAt: 1})或{createdAt: -1}，方向要和sort()一致 - 复合游标（如
{status: 1, createdAt: -1}）：索引顺序必须和查询条件 + 排序完全一致，且status等过滤字段要在前——否则无法应用最左前缀原则 - 验证是否命中索引：用
db.collection.find(...).sort(...).explain("executionStats")，确认executionStages.stage === "IXSCAN"，且没有"stage": "SORT"
真正难的不是写对那条 $gt 查询，而是让整个链路（查询条件、排序、索引定义、游标字段唯一性）严丝合缝。少一个环节，性能就掉回 skip() 的老路。
