请教后端分页的常用方法

mysql 的话每次都得手动 count 一下，其他引擎不一定。比如 es 每次都会自动返回 total

无解。前端做一下缓存吧，查询条件变化就清掉

不 count 总数量的话，可以把数据按固定顺序排列，每次加载上一页最后一条数据之后的 N 条数据。

如果只允许连续一页页翻，不需要做成输入页码直达任意页面的话，类似朋友圈这种，可以带上次结果最后一条的 id 作为过滤条件

如果你数据量不变（不新增，不修改，不带过滤）那么你可以全局变量存下 count 值来省掉这个查询

@lovelylain #4 在常规业务中，列表还是需要 total 的，无限刷新的不适合这种场景。而且在通常的业务中，CURD 需要实时性，所以缓存其实不是“那么地”必要。

@opengps 一般都是变化的呢

如果数据规模不大，查询结果的行数在几千行以内，通常不需要特别优化，直接 count(1) 不会有大的性能问题。

如果数据规模较大，查询结果行数在几十万行规模以上级别，这时候翻页都是麻烦事儿。一般会在数据库内另外记一个值来存手动 count ，每次新增行 count + 1 ，每次删除行 count - 1 ，通过事务来确保与实际行数一致。
比如知乎的粉丝列表页面： https://www.zhihu.com/people/gong-qing-tuan-zhong-yang-67/followers?page=2333
翻页翻到后面直接不展示数据了，因为此时数据库需要 skip 上万行才能查询到结果，开销太大了。

另外一个很实用的办法是把分页换成加载 [加载更多]，这样就不用 count 了，用户也更难 skip 上万行。

分页 count 才是小问题，mysql 数据量大了以后 limit offset 才是大问题，如果你连 limit offset 的问题都遇不到，那考虑 count 的问题真的是庸人自扰

你细想一下，如果你想精确展示 总页数，这个 count 值是肯定需要的对吧？ 查询是避免不了的。

如果你觉得每次查询有点浪费，那缓存的作用就是减少 DB 查询压力的，所以上缓存就好了，至于前端缓存还是后端缓存看你的业务；
缓存更新机制则看数据实时性要求，要求比较低可以设置个几分钟自动过期都行。

但如其他楼提到的，相比于 count ，翻页到很后面的时候 limit offset 的问题一般更大一点，DB 要抛掉非常多的数据才能取到当前页。

所以现在蛮多地方都直接不显示总页数，而是”前一页 /后一页“的方式，因为很少有人真的翻到非常后面的页数，不必要花大力气支持这个伪需求。