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