700W 数据的表，如何做分页查询，速度不低于 1s

表结构、查询条件、索引一个都不说，没法回你啊

从性能角度出发，应该没有能超过 google chrome 的 leveldb 数据库的存在了。

就是单纯的快。

大翻页做不到

有个妥协方案是带上游标

一般产品方案上也会约束这种想看第 50 万页数据的请求

都是伪需求，一页 100 条也得 7w 页，你会去看第 6w 页的数据嘛？

问下,你要速度不低于 1s 的意思,是查询返回时间要超过 1s 吗?

想要超过 1s 还真挺难的

pk 有序 uuid 或自增 id

列表限死 100 页

复杂筛选过滤条件（时间区间+订单号+商品名称模糊搜索+...+）上 ES 或者 FTS


哪个产品说要看第 101 页的就地拍死

不低于 1s 还有这么无理取闹的要求吗?

不如来个 3 秒钟的加载动画，就像苹果手机一样，老板会觉得搜索很丝滑，一点都不卡

滚动加载 + 翻页 ？

有一个老业务，阿里云 RDS2 核 4G 有一个表，2 亿数据条数据（主要业务非日志），一直没空改，大概页面平均相应时间 200MS 内吧。

首先你得查询索引数据分散，分页查询才会快，否则文件排序肯定慢。

比如一个论坛总共 100 万帖子，但是某个版块帖子有几万条，分页时文件排序和 COUNT 就会慢；
如果是一个电商网站，订单记录虽然有 1000 万，但是一个用户也就不到一千条记录，分页时排序和 COUNT 都很快。

如果时第一种场景，楼上有答案：1，不要 count ； 2，不然看超过 1000 页的。百度贴吧都是这样的。

现在贴吧改进了，直接可以到最后一页了，估计技术改进了。

其实我对低于 1s 的方案更感兴趣

@encro 昨天看贴吧，点 1000 多页，显示的是当天的很奇怪的问题

告诉产品 这个需求不做。

线上 mysql 数据库 13626210 条数据，select * from Table order by id desc limit 1000, 100; （ id 是主键），查询想超过 1s 很难

@supermoonie


select * from Table order by id desc limit 10000000, 100;

就会慢了。

@supermoonie 试试楼上说的，limit 越深性能下降越厉害

@encro 我明天试试

@pcbl 明天

分页查询在大数据量，多种复合条件查询 的时候 , 确实都比较麻烦 ，没有什么太好的办法

700W 真的不带条件查询的吗..

我们是 40 亿条数据，不过查询用的 es，速度远小于 1 秒，而且大数据的分页这个需求有点没必要把，肯定要带条件。就像上面那个老哥说的，谁会去看第 6w 页的数据。

我用 HBase，几亿数据（浙江农业银行），分页也是秒返回。根据不同业务，将 RowKey 拼接好就行了，上 Es 表也是可以的。

做那么多分页,人是不会去看 100 页后面的了, 反而给了机会给那些爬虫的程序,分分钟拖垮你数据库.
要么是有查询条件.

使用内存数据库，或者傲腾 p5800X 级别固态。

单表 2k 多万，id 是自增，非自增情况，可用雪花算法支持排序，这个我没实际用过，我都是用自增
SELECT * FROM `ht` LIMIT 20049925, 30; // 9.283s
SELECT * FROM `hanting` WHERE id>20049925 LIMIT 30; // 0.001s

前一页的最大行 id，根据 id 来限制起点，微信粉丝列表接口中要传 openid 估计就是这么个理

加条件估计做不到吧，上 elasticsearch

HBase 直接干，TB 级别

一般都是通过自增 id 解决，搜索条件带上 id

700W 如果只是单表查询感觉还是比较 ok.
分页查询主要查了两次 第一次查 count(1),第二次具体分页,大数据可以采用 more 的策略,比如你要查 20 条的数据,你可以查 21 条,返回 20 条,然后告诉前端还有更多,这样就节省一次 count 查询.

@3dwelcome leveldb 能分页？？

如果底层使用 mysql 不变的情况，可以采用瀑布流的，使用最大 id 来查询分页，这样效率不会低

用 es 吧

@xiaowei7777 #34 es 也不行，es 只能考虑游标，且 es 默认限制只能 Limit 10000

加上索引，去掉 order，

别用 limit
用 where id>
或者 redis zset 分页

QQ 群关系数据库 几十亿条数据 group 是按 qq 号分的表 QQ 号 /100000 向下取整 为一张表 这样你通过 QQ 号查找 动态拼接表名 就能缩小范围

@ruanimal " leveldb 能分页？？"

弄个自增长 ID 当 KEY，粗略分页呗，chrome 的 indexedDB 就是这样做的。

主要是 key-value 数据库查询快啊。

用 mysql 做过亿级订单数据分页，先用订单时间做数据库分区检索再做分页，结果效果一般，特别是碰到跨区的时候。。更别说加上一些复杂的筛选条件了。。

最后在掐死产品之前，把订单数据迁移到了 Hbase 。。

生产一千多万的数据，查询时间在 500 ～ 800ms, 合理利用索引，干掉复杂查询

不用 limit 使用 ID 做 cursor

评论少了一个方案。
1 、首先你单表做查询完全不是问题，有索引足够快了，每次查询带上上一次的索引值即可。
2 、但是如果你想看到好几万页的数据怎么办？这个其实就是 mongodb 那种分布式数据库的 分页方案了，你创建一个新的表去维护这个大表的分页 ID 就可以了（如果数据经常写入和删除的话，这维护的成本还是挺高的，适合读多写少的），完全不是问题。
3 、其他的答案就是 ES，HBase 这种数据库作为首选，或者备份。

用 es limit 也不是后面会越来越慢的吗?
用 id 作为条件分页 应该还好吧

加索引就足够快了，通过 id 来翻页，
我们单表单库两亿多数据
select max(id) from xxx; 262992300 条
select * from xxx where id > 262991800 limit 10;
通过这种方式来检索 0.041s