api返回结果数的优化

Question

返回一个列表时往往有如下的结构：

{
    'total': 30,
    'items': {...}
}

但这种做法是昂贵的，因为做了两次查询，一次查数量，一次查数据。所以演变出下面这种结构（stackoverflow是这种做法）：

{
    'hasMore': true,
    'items': {...}
}

如何知道后面有没有数据呢？

方案1：

比方查 page=1 的数据，同时查一次 page=2 得出这个 hasMore 的值，当然这个比查 total 开销是要小点。

方案2：

查出 total 的值，缓存起来，但是会有实效问题

各位是如何处理这个问题的？

Answer 1

作为前端其实我喜欢第一种数据格式,因为我需要根据total来进行分页,准确的告诉用户还有多少页,尤其是当条数可能实时变化的时候,那么分页的页数也可能是实时变化的.

Answer 2

我觉得api只要查询每次的分页数据就好了，是否有数据前段可以判断下

Answer 3

把hasMore的来源改成,先每次查询newLimit=pagelimit+1的记录，hasMore=list.size()>pagelimit?true:false，同时list只返回limit条数据，也就是看看有没有下一条而不是下一页，不过其实保证分页的实效性意义不大

Answer 4

一定要用到 total 吗? 如果没有根本不必下发.

比如我项目里下拉刷新下一页数据, 直到没有就提示没有数据, 并且再次下拉不再请求api.

Answer 5

后台根据查询条件hash一个key 每回请求前端传key和total

通过key和查询条件hash对比
以及total和(page_no - 1) * page_size + result
来决定是否查询total