分页查询，查个 total 很难吗？

[wxsm]

如题。一个破接口，后端开发人员三番五次说要不传 total，让我去别的地方取，说什么查个 total 相当全表扫，我真是服气。

[killerv]

InnoDB 引擎的大表 count 确实慢，可以考虑缓存 count，插入和删除行的时候实时更新缓存。

[nszm]

@whypool #33 有个搜索条件

[slime7]

某绿帽论坛的查询会显示灰色页码，tooltip 提示可能有 xx 页，直到点到某页后没数据

[ty89]

不好说，这个得看业务情况具体分析，不过多数情况下用假分页就行了，比如微博的 timeline，不可能给你算 total 的

[hadixlin]

楼主的基础知识薄弱呀，这个 count 的问题可能是很复杂的优化，考虑成本来说，一般都是不做的

[logOo]

@wangbenjun5 嗯，你这个思路很好。

[jadec0der]

笑~很多时候前端开发表现的像普通用户一样。

不知道你是多大的数据量，数据量大了以后 total 确实很难取，很多场景都是估算或者只给前面一部分结果，比如 Google 搜索，result 数量是估算的，翻页一般也只能翻几十页

[panlilu]

数据量大的情况查 total 是挺难的……

[3a3Mp112]

根本没说清楚这个 total 指的是什么数据，是每次请求回来的有效数量，还是什么？

[w0000]

数据大，有 where 条件，条件多并且组合也多的时候，是快不了的啊楼主

[Immortal]

其实看完描述我有几个问题和想法
1、从别的地方取是哪里取？如果他这个接口里不好传，别的地方就能传了？
2、这个应该不是全表扫，会走主键索引应该，都不会回表才是

结果和楼上们说的一样，得看数据量才能决定，不是百万千万的 count 还是很快的，如果有连续主键都不用 count，取最大自增主键就好。以前我也经常和客户端吵这类问题，因为我发现他们没法理解服务端需要考虑的问题。归根结底还是没好好沟通，两边都有点责任，抽个时间和服务端聊下解决方案好了。具体服务端的优化方式楼上很多了。

[MushishiXian]

有时候 count 真的会挺慢的,加缓存你又要考虑各种查询条件,如果这个 total 不是特别重要,就真的没必要去 count

[jydeng]

total 确实很复杂，我们现在表数据量小的话，一般查询两次，一次查 total，一次分页查具体数据。

[iyaozhen]

抛开数据量和场景都是耍流氓

[vincenttone]

- 如果数据量大做了分表，恐怕后端就需要做个计数器（还不一定保证准确）。
- 如果数据量小不做分表，多一次 IO。可以不扫全表，前提是有可用的索引。

[sm0king]

不管什么原因，该一个请求返回过来的数据，非要请求两条，还有，丢过来一堆数据让前端自己做数据处理对接的后台，都是偷懒。

[play78]

这个还是要根据实际业务来， 如果是必须的，那就提供呗。客户能接收等待时间，就多等几秒。
如果业务中，不是必须的，就不用了。
例如，查询记录类的数据。只要告诉用户有下一页就可以。不用提供总共有多少页。让用户一直下一页，下一页。
又比如，一些动态排名之类的。可以后端起个定时任务，每 10 分钟更新一次数据。
如果是要求实时类的，比如一些余额。那就必须要每次都统计了。

[JamesPan]

@kera0a myisam count 很快，innodb count 真的是扫全表，可以用 explain 得到的影响行来大致顶替 count

[glues]

ls 的某些高手很多啊，吹牛不要钱是吗？

[Sunshow]

是很难，没必要最好别用