这是一个创建于 1239 天前的主题，其中的信息可能已经有所发展或是发生改变。
mysql ,700W 数据的表，如何做分页查询，速度不低于 1s
第 1 条附言 · 2021-07-14 16:20:39 +08:00
我傻比了
是查询时间 低于 1s
是查询时间 低于 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 |
Select Language