API 分页探讨:offset 来分页真的有效率?
对于设计和实现 API 来说,当结果集包含成千上万条记录时,返回一个查询的所有结果可能是一个挑战,它给服务器、客户端和网络带来了不必要的压力,于是就有了分页的功能。 通常我们通过一个 offset 偏移量或者页码来进行分页,然后通过 API 实现类似请求: GET /api/products? page =10 { "items" : [ .. .100 products]} 如果要继续访问后续数据,则修改分页参数即可。 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