mysql ,700W 数据的表,如何做分页查询,速度不低于 1s
1
des 2021-07-14 12:30:14 +08:00 via iPhone 3
表结构、查询条件、索引一个都不说,没法回你啊
|
2
3dwelcome 2021-07-14 12:32:25 +08:00
从性能角度出发,应该没有能超过 google chrome 的 leveldb 数据库的存在了。
就是单纯的快。 |
3
Jooooooooo 2021-07-14 12:35:15 +08:00
大翻页做不到
有个妥协方案是带上游标 一般产品方案上也会约束这种想看第 50 万页数据的请求 |
4
aragakiyuii 2021-07-14 12:46:45 +08:00 via iPhone 2
都是伪需求,一页 100 条也得 7w 页,你会去看第 6w 页的数据嘛?
|
5
ReysC 2021-07-14 13:01:48 +08:00 1
问下,你要速度不低于 1s 的意思,是查询返回时间要超过 1s 吗?
|
6
Thinklong 2021-07-14 13:12:24 +08:00 5
想要超过 1s 还真挺难的
|
7
dzdh 2021-07-14 13:18:04 +08:00
pk 有序 uuid 或自增 id
列表限死 100 页 复杂筛选过滤条件(时间区间+订单号+商品名称模糊搜索+...+)上 ES 或者 FTS 哪个产品说要看第 101 页的就地拍死 |
8
jier17cm 2021-07-14 14:45:05 +08:00 1
不低于 1s 还有这么无理取闹的要求吗?
|
9
pcbl 2021-07-14 15:05:38 +08:00 via Android 3
不如来个 3 秒钟的加载动画,就像苹果手机一样,老板会觉得搜索很丝滑,一点都不卡
|
10
dingdangnao 2021-07-14 15:12:12 +08:00
滚动加载 + 翻页 ?
|
11
encro 2021-07-14 15:16:00 +08:00
有一个老业务,阿里云 RDS2 核 4G 有一个表,2 亿数据条数据(主要业务非日志),一直没空改,大概页面平均相应时间 200MS 内吧。
首先你得查询索引数据分散,分页查询才会快,否则文件排序肯定慢。 比如一个论坛总共 100 万帖子,但是某个版块帖子有几万条,分页时文件排序和 COUNT 就会慢; 如果是一个电商网站,订单记录虽然有 1000 万,但是一个用户也就不到一千条记录,分页时排序和 COUNT 都很快。 如果时第一种场景,楼上有答案:1,不要 count ; 2,不然看超过 1000 页的。百度贴吧都是这样的。 |
12
encro 2021-07-14 15:18:28 +08:00
现在贴吧改进了,直接可以到最后一页了,估计技术改进了。
|
13
wangsongyan 2021-07-14 15:57:31 +08:00
其实我对低于 1s 的方案更感兴趣
|
14
robinchina 2021-07-14 17:20:11 +08:00
@encro 昨天看贴吧,点 1000 多页,显示的是当天的····很奇怪的问题
|
15
hejw19970413 2021-07-14 17:34:32 +08:00
告诉产品 这个需求不做。
|
16
supermoonie 2021-07-14 17:41:45 +08:00
线上 mysql 数据库 13626210 条数据,select * from Table order by id desc limit 1000, 100; ( id 是主键),查询想超过 1s 很难
|
17
encro 2021-07-14 17:57:32 +08:00
|
18
pcbl 2021-07-14 19:26:21 +08:00 via Android
@supermoonie 试试楼上说的,limit 越深性能下降越厉害
|
19
supermoonie 2021-07-14 19:33:12 +08:00 via iPhone
@encro 我明天试试
|
20
supermoonie 2021-07-14 19:33:23 +08:00 via iPhone
@pcbl 明天
|
21
akira 2021-07-14 20:59:44 +08:00
分页查询在大数据量,多种复合条件查询 的时候 , 确实都比较麻烦 ,没有什么太好的办法
|
22
2kCS5c0b0ITXE5k2 2021-07-14 21:01:08 +08:00
700W 真的不带条件查询的吗..
|
23
LING97 2021-07-14 23:49:16 +08:00
我们是 40 亿条数据,不过查询用的 es,速度远小于 1 秒,而且大数据的分页这个需求有点没必要把,肯定要带条件。就像上面那个老哥说的,谁会去看第 6w 页的数据。
|
24
young1lin 2021-07-14 23:53:27 +08:00
我用 HBase,几亿数据(浙江农业银行),分页也是秒返回。根据不同业务,将 RowKey 拼接好就行了,上 Es 表也是可以的。
|
25
yagamil 2021-07-15 07:50:05 +08:00 1
做那么多分页,人是不会去看 100 页后面的了, 反而给了机会给那些爬虫的程序,分分钟拖垮你数据库.
要么是有查询条件. |
26
huang119412 2021-07-15 08:53:37 +08:00
使用内存数据库,或者傲腾 p5800X 级别固态。
|
27
wowbaby 2021-07-15 09:12:23 +08:00
单表 2k 多万,id 是自增,非自增情况,可用雪花算法支持排序,这个我没实际用过,我都是用自增
SELECT * FROM `ht` LIMIT 20049925, 30; // 9.283s SELECT * FROM `hanting` WHERE id>20049925 LIMIT 30; // 0.001s 前一页的最大行 id,根据 id 来限制起点,微信粉丝列表接口中要传 openid 估计就是这么个理 |
28
wowbaby 2021-07-15 09:20:00 +08:00
加条件估计做不到吧,上 elasticsearch
|
29
ZeroDu 2021-07-15 09:25:34 +08:00
HBase 直接干,TB 级别
|
30
linbiaye 2021-07-15 09:33:35 +08:00
一般都是通过自增 id 解决,搜索条件带上 id
|
31
ebony0319 2021-07-15 09:37:26 +08:00
700W 如果只是单表查询感觉还是比较 ok.
分页查询主要查了两次 第一次查 count(1),第二次具体分页,大数据可以采用 more 的策略,比如你要查 20 条的数据,你可以查 21 条,返回 20 条,然后告诉前端还有更多,这样就节省一次 count 查询. |
33
echoZero 2021-07-15 10:12:25 +08:00
如果底层使用 mysql 不变的情况,可以采用瀑布流的,使用最大 id 来查询分页,这样效率不会低
|
34
xiaowei7777 2021-07-15 10:26:25 +08:00
用 es 吧
|
35
pkwenda 2021-07-15 10:32:09 +08:00
@xiaowei7777 #34 es 也不行,es 只能考虑游标,且 es 默认限制只能 Limit 10000
|
36
KouShuiYu 2021-07-15 10:32:20 +08:00
加上索引,去掉 order,
|
37
wangyzj 2021-07-15 10:35:02 +08:00
别用 limit
用 where id> 或者 redis zset 分页 |
38
leqoqo 2021-07-15 10:40:18 +08:00
QQ 群关系数据库 几十亿条数据 group 是按 qq 号分的表 QQ 号 /100000 向下取整 为一张表 这样你通过 QQ 号查找 动态拼接表名 就能缩小范围
|
39
3dwelcome 2021-07-15 11:32:32 +08:00
|
40
zhouyou457 2021-07-15 11:36:13 +08:00
用 mysql 做过亿级订单数据分页,先用订单时间做数据库分区检索再做分页,结果效果一般,特别是碰到跨区的时候。。更别说加上一些复杂的筛选条件了。。
最后在掐死产品之前,把订单数据迁移到了 Hbase 。。 |
41
v2hh 2021-07-15 11:48:21 +08:00
生产一千多万的数据,查询时间在 500 ~ 800ms, 合理利用索引,干掉复杂查询
|
42
tonghuashuai 2021-07-15 13:11:02 +08:00
不用 limit 使用 ID 做 cursor
|
43
byte10 2021-07-15 15:09:14 +08:00
评论少了一个方案。
1 、首先你单表做查询完全不是问题,有索引足够快了,每次查询带上上一次的索引值即可。 2 、但是如果你想看到好几万页的数据怎么办?这个其实就是 mongodb 那种分布式数据库的 分页方案了,你创建一个新的表去维护这个大表的分页 ID 就可以了(如果数据经常写入和删除的话,这维护的成本还是挺高的,适合读多写少的),完全不是问题。 3 、其他的答案就是 ES,HBase 这种数据库作为首选,或者备份。 |
44
yagamil 2021-07-15 15:49:50 +08:00
用 es limit 也不是后面会越来越慢的吗?
用 id 作为条件分页 应该还好吧 |
45
liuyx7894 2021-07-15 18:11:38 +08:00
加索引就足够快了,通过 id 来翻页,
我们单表单库两亿多数据 select max(id) from xxx; 262992300 条 select * from xxx where id > 262991800 limit 10; 通过这种方式来检索 0.041s |