API 分页探讨：offset 来分页真的有效率吗？

如果要继续访问后续数据，则修改分页参数即可。

GET /api/products?page=11

{“items”: […another 100 products]}

在使用 offset 的情况下，通常使用 ?offset=1000 和 ?offset=1100 这种大家都熟悉的方法。它要么直接调用 OFFSET 1000 LIMIT 100 的 SQL 查询数据库，要么使用 LIMIT 乘以 page 作为查询参数。

无论如何，「这是一个次优的解决方案」，因为无论哪种数据库都要跳过前面 offset 指定的 1000 行。而跳过额外的offset，不管是 PostgreSQL，ElasticSearch还是 MongoDB 都存在额外开销，数据库需要对它们进行排序，计数，然后将前面不用的数据扔掉。

这是一种低效的方法，但由于它使用简单，所以大家重复地用这个方法，也就是直接把 API 参数映射到数据库查询上。

那合适的方法是什么？介绍之前我们可以先看看数据库的实现。在数据库中有一个游标（cursor）的概念，它是一个指向行的指针，然后可以告诉数据库：“在这个游标之后返回 100 行”。这个指令对数据库来说很容易，因为你很有可能通过一个索引字段来识别这一行。然后就不需要去取和跳过前面那些没用到的记录了。

举个例子。

GET /api/products

{“items”: […100 products],

“cursor”: “qWe”}

API 返回一个无业务意义的字符串（游标），你可以用它来检索下一个页面。

GET /api/products?cursor=qWe

{“it