一、为什么深分页会慢？
我们在日常开发中，经常遇到需要从数据库里把数据一页一页翻出来的需求。比如一个用户列表，用户想翻到第 100 页，每页显示 20 条。对于关系型数据库，我们习惯用 limit offset。但在 JanusGraph 这样的图数据库里，事情变得复杂了。JanusGraph 底层存储的是点、边和属性，查询往往涉及遍历。
1.1 数据库的视角
想象一下，你要在一本巨大的电话簿里找第 10000 个名字。如果你不知道索引，你必须从第 1 页开始，数到第 10000 页。数据库在执行 skip(10000).limit(20) 时，内部逻辑往往也是这样。它必须先找到前 10000 条记录，丢弃它们，然后把剩下的 20 条给你。这个过程消耗了大量的 CPU 和内存，因为数据库并没有“跳过去”的能力，它必须“走过”那些被跳过的记录。随着页码增加，页数越深，跳过的记录越多，耗时呈线性甚至指数增长。这就是为什么深分页查询性能会暴跌，页面卡死，接口超时。
二、传统 offset 方式的坑
很多开发者沿用 SQL 的思维写 Gremlin 查询，导致系统上线后在大流量下崩溃。我们来看一段典型的代码，它是多么具有迷惑性，却又隐藏着巨大的性能风险。
// 技术栈：Java
// 场景：尝试使用传统的 offset 方式获取 JanusGraph 中的用户数据
// 问题：当 offset 值很大时，数据库需要扫描大量无用数据
import org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource;
public class BadPaginationExample {
public List<Vertex> getUsers(GraphTraversalSource g, int page, int pageSize) {
int offset = (page - 1) * pageSize;
// 这里是关键问题所在，skip 操作在图数据库中效率极低
// 数据库必须先定位到 offset 位置，才能开始取数据
return g.V()
.hasLabel("user")
.skip(offset) // 浪费资源：跳过前 N 条记录
.limit(pageSize) // 只取当前页
.toList();
}
}
在这段代码里，skip 是罪魁祸首。当 page 是 1 时，offset 是 0，没问题。但当 page 是 1000 时，offset 就是 20000。JanusGraph 必须遍历索引中的前 20000 个条目，确认它们存在，然后丢弃它们。这不仅慢了，还会占用连接池资源。在高并发下，大量这样的查询会瞬间打满数据库 CPU，导致整个服务不可用。我们必须抛弃这种思维，寻找更聪明的方法。
三、基于游标分页的实现
为了解决这个问题，我们引入“游标”的概念。游标就像你在看书时夹的书签。你不需要每次都从第一页开始数，你只需要记住上次看到哪一页，下次从那一页继续往后看。在数据库里，这个“书签”通常是最后一条记录的 ID。
3.1 核心逻辑
游标分页的核心在于“记住上次的位置”。第一次查询时，我们正常获取第一页数据，并记录下最后一条记录的 ID。当用户点击“下一页”时，我们把这个 ID 传给后端。后端查询时，不再跳过前 N 条，而是直接查询“ID 大于上次 ID"的记录。这样，数据库可以直接利用索引定位到位置，不需要扫描之前的数据。
// 技术栈：Java
// 场景：使用游标（基于 ID）实现高效分页
// 优点：查询速度稳定，不受页码深度影响
import org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource;
import org.apache.tinkerpop.gremlin.structure.Vertex;
public class CursorPaginationExample {
// 初始查询：无游标，获取第一页
public List<Vertex> getFirstPage(GraphTraversalSource g, int pageSize) {
return g.V()
.hasLabel("user")
.order().by("id", org.apache.tinkerpop.gremlin.process.traversal.Order.asc) // 必须排序保证一致性
.limit(pageSize)
.toList();
}
// 后续查询：携带游标，获取下一页
// lastId 是上一页最后一条记录的 ID
public List<Vertex> getNextPage(GraphTraversalSource g, String lastId, int pageSize) {
return g.V()
.hasLabel("user")
.hasId(org.apache.tinkerpop.gremlin.process.traversal.P.gt(lastId)) // 核心：大于游标
.order().by("id", org.apache.tinkerpop.gremlin.process.traversal.Order.asc)
.limit(pageSize)
.toList();
}
}
这种方法的效率非常高，因为数据库可以直接从索引树中找到 lastId 的位置，然后向右读取数据。无论你是第 1 页还是第 1000 页，查询的耗时基本是一样的。这就像跳楼机，你可以直接停在第 1000 层，而不需要一层层爬上去。
四、基于键集分页的优化
游标分页虽然好，但如果数据有重复 ID 或者排序字段不唯一，可能会出问题。这时候我们需要“键集分页”，也就是基于多个字段排序。比如按时间戳排序，如果时间戳一样，再按 ID 排序。这样可以保证每一页的数据都是唯一且有序的。
4.1 复合排序策略
在实际业务中，比如朋友圈动态，我们通常按时间倒序排列。为了防止时间戳相同导致漏数据或重复数据，我们需要引入一个唯一键，通常是主键 ID。查询条件变成了“时间小于上一次最后一条的时间，或者时间等于但 ID 小于上一次 ID"。
// 技术栈：Java
// 场景：基于时间戳和 ID 的键集分页，适用于动态流、消息列表
// 优点：数据顺序稳定，避免并发写入导致的数据重复或丢失
import org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource;
import org.apache.tinkerpop.gremlin.structure.Vertex;
public class KeysetPaginationExample {
// lastTime 为上一页最后一条的时间戳，lastId 为对应的 ID
public List<Vertex> getFeed(GraphTraversalSource g, long lastTime, String lastId, int pageSize) {
return g.V()
.hasLabel("post")
.and(
__.has("createdTime", org.apache.tinkerpop.gremlin.process.traversal.P.lt(lastTime)), // 时间更早
__.and(
__.has("createdTime", org.apache.tinkerpop.gremlin.process.traversal.P.eq(lastTime)),
__.hasId(org.apache.tinkerpop.gremlin.process.traversal.P.lt(lastId)) // 同时间下 ID 更小
)
)
.order().by("createdTime", org.apache.tinkerpop.gremlin.process.traversal.Order.desc)
.order().by("id", org.apache.tinkerpop.gremlin.process.traversal.Order.desc)
.limit(pageSize)
.toList();
}
}
这段代码看起来比游标复杂一点，但它解决了并发写入的问题。假设两个人在同一毫秒发了动态，单纯按时间排可能会乱。加上 ID 排序后，顺序就固定了。这种方案在实时性要求高的系统中非常关键。
五、应用场景分析
并不是所有场景都需要这么复杂的优化。我们需要根据业务特点来选择方案。
对于后台管理系统的用户列表，如果数据量在万级别，传统的 offset 可能还能凑合，但性能会随数据增长变差。如果数据量达到百万甚至亿级，必须使用游标或键集分页。
对于面向用户的无限滚动页面，比如资讯流、社交动态、商品列表，游标分页是标配。用户很少会跳页，他们总是向后翻。这种“向前不向后”的习惯完美契合游标逻辑。
对于需要随机跳转的场景，比如搜索引擎结果，游标就不适用了。这时候可能需要结合缓存或者预计算页码索引，但这超出了普通分页优化的范畴，属于架构层面的设计了。
六、技术优缺点对比
我们客观地分析一下这三种方式的优劣，帮助你在架构评审时更有底气。
传统 Offset 分页优点是代码简单，逻辑直观，支持任意页跳转。缺点是性能随深度线性下降，资源浪费严重，不适合大数据量。
游标分页优点是性能稳定，消耗资源少，实现相对简单。缺点是不支持任意页跳转，只能上一页下一页翻，如果用户想跳回第 5 页，必须从头翻或者缓存状态。
键集分页优点是数据一致性最好，支持复杂排序，适合高频写入场景。缺点是查询语句稍微复杂，需要精心设计排序字段组合，对索引要求较高。
七、注意事项
在实施优化时，有几个坑必须避开。
首先是索引。无论用游标还是键集，排序字段和过滤字段必须有索引。如果没有索引，JanusGraph 还是会全表扫描，性能优化就白做了。你需要检查你的 Schema，确保 id 或 createdTime 上建有合适的索引。
其次是并发安全。在查询过程中，如果有新数据插入，游标分页可能会漏掉数据或重复数据。键集分页通过复合排序能缓解这个问题，但不能完全消除。对于要求严格的数据完整性场景，可能需要引入版本控制。
最后是前端配合。后端改了接口，前端也必须改。前端不能再传 page 参数，而要传 cursor 或 lastId。前端还需要处理“没有下一页”的情况，即返回数据不足 pageSize 时，停止拉取。
八、文章总结
JanusGraph 深分页性能问题本质是数据库扫描机制导致的。通过放弃传统的 Offset 思维，转向基于游标或键集的分页策略，我们可以将查询复杂度从线性降低到常量级别。游标适合简单的 ID 排序，键集适合复杂的时间排序。两者都能显著提升系统在高并发下的稳定性。作为开发者，理解数据是如何被存储和检索的，比背诵代码更重要。希望这些实战经验能帮你解决生产环境中的性能痛点，让系统运行得更加流畅。
评论
围绕“JanusGraph深度分页查询性能暴跌怎么破？基于游标与键集分页的完整优化方案与实战经验”参与讨论