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

[wxsm]

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

[EmdeBoas]

@winglight2016 kylin 就是做预计算的，支持百亿级数据查询毫秒出结果...一般查历史数据的时候好用，比如说今天 4-2 号，你只需要查 4-1 号以及之前的数据，就比较适用，每天写个定时任务，增量把前一天的数据预计算好给第二天用。kylin 搭起来跟维护的成本相当大的...

[EmdeBoas]

@nigelvon 然而查询条件会变，数据的量也可能在变

[VincentWang]

@nigelvon 不太好缓存吧，即使不考虑数据库里的数据量在变化，查询条件也会变。

[nigelvon]

@EmdeBoas 数据变更不会更新缓存？查询条件组合多不会多设置几条缓存组合？
恕我直言，连 total 都不愿意给的后端我不信数据多到 count 都慢的程度

[linbiaye]

如果是 Mysql 的 InnoDB 的 count 不带 where 就是全表扫描，带了 where 看具体的 where，所以后端说的没毛病，表大了没有利用好索引或者没法利用索引就是很慢。

[abusizhishen]

他可以对指定来源屏蔽这个参数

[EmdeBoas]

@nigelvon .....我最近做的查询条件组合起来可能有上万种....做 count 多 9 秒起...

[sagaxu]

@nigelvon 查询条件的组合，数量是乘起来的，超过几十个的时候，更新缓存的成本会很高

[nigelvon]

@EmdeBoas 你这根本就不光是 count 的问题，连数据都查不出来，上搜索引擎。从楼主描述来看取数据没问题，那么 count 不存在简单方案解决不了的性能问题。

[scnace]

实时数据的 Count 真的很麻烦(耗性能) 分页那种 Case 的话 可以把 Total 拉到比较大 或者 同意楼上的维护单独表 count 的做法(鸟书也推荐这么做) P.S. es 并不是银弹 也要考虑到多个数据源的维护成本

[eslizn]

@nigelvon 取数据没问题不代表 count 没问题

[EmdeBoas]

@nigelvon 老哥，你这根本不讲道理，你又不知道实际情况，你以为想用搜索引擎就用？都得结合自己组有的资源，解决方法有一万种，但更重要的是资源复用和可维护性

[whypool]

话说，数据量多的时候存自增 id，拿 max 会不会快点？

[debuggerx]

上个项目里有个查询，数据量大概在 300W 左右，每次都查出 count 的话还是比较影响性能的，查询一般在 1~3 秒，但是分析下来这个接口是一个下滑展示，而且没有提供转跳到某一页的功能，也就是说有用户死命地不停滑动也要一天才会请求到最后的数据，于是我专门给这个接口写了个分页查询，total 从 redis 里取，redis 里的值只在每天凌晨更新一次……

[startar]

如果后端是单纯的 db 的话，实时查 count 确实有可能很慢啊。一般都要扫索引。如果真要实时查就得预计算，上 kylin。
建议对自己不熟悉的领域不要那么想当然。。

[Socket]

似曾相识，这玩意儿没 total 可不行，panigation 这种组件不传 total 没法展示页码，你只能点一下查一下，有就展示，没有就展示没数据

[cheetah]

哈哈看看豆瓣广播现在也没总页数

[arslion]

不讲清楚场景发这帖子干嘛？

[wangbenjun5]

说实话,那种几百上千万的数据表你们分页是给人看的吗?

[wwdyy]

那就跟产品说，后端说做不了分页，只能做下一页这样的