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

[kikione]

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

我傻比了

是查询时间 低于 1s

[des]

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

[3dwelcome]

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

就是单纯的快。

[Jooooooooo]

大翻页做不到

有个妥协方案是带上游标

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

[aragakiyuii]

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

[ReysC]

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

[Thinklong]

想要超过 1s 还真挺难的

[dzdh]

pk 有序 uuid 或自增 id

列表限死 100 页

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


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

[jier17cm]

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

[pcbl]

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

[dingdangnao]

滚动加载 + 翻页 ？

[encro]

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

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

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

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

[encro]

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

[wangsongyan]

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

[robinchina]

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

[hejw19970413]

告诉产品 这个需求不做。

[supermoonie]

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

[encro]

@supermoonie


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

就会慢了。

[pcbl]

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

[supermoonie]

@encro 我明天试试

[supermoonie]

@pcbl 明天

[akira]

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

[2kCS5c0b0ITXE5k2]

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

[LING97]

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

[young1lin]

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

[yagamil]

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

[huang119412]

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

[wowbaby]

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

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

[wowbaby]

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

[ZeroDu]

HBase 直接干，TB 级别

[linbiaye]

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

[ebony0319]

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

[ruanimal]

@3dwelcome leveldb 能分页？？

[echoZero]

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

[xiaowei7777]

用 es 吧

[pkwenda]

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

[KouShuiYu]

加上索引，去掉 order，

[wangyzj]

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

[leqoqo]

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

[3dwelcome]

@ruanimal " leveldb 能分页？？"

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

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

[zhouyou457]

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

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

[v2hh]

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

[tonghuashuai]

不用 limit 使用 ID 做 cursor

[byte10]

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

[yagamil]

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

[liuyx7894]

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