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

[kikione]

mysql ,700W 数据的表，如何做分页查询，速度不低于 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 明天