V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
kikione
V2EX  ›  程序员

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

  •  1
     
  •   kikione · 2021-07-14 12:15:41 +08:00 · 7016 次点击
    这是一个创建于 988 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    第 1 条附言  ·  2021-07-14 16:20:39 +08:00
    我傻比了

    是查询时间 低于 1s
    45 条回复    2021-07-15 18:11:38 +08:00
    des
        1
    des  
       2021-07-14 12:30:14 +08:00 via iPhone   ❤️ 3
    表结构、查询条件、索引一个都不说,没法回你啊
    3dwelcome
        2
    3dwelcome  
       2021-07-14 12:32:25 +08:00
    从性能角度出发,应该没有能超过 google chrome 的 leveldb 数据库的存在了。

    就是单纯的快。
    Jooooooooo
        3
    Jooooooooo  
       2021-07-14 12:35:15 +08:00
    大翻页做不到

    有个妥协方案是带上游标

    一般产品方案上也会约束这种想看第 50 万页数据的请求
    aragakiyuii
        4
    aragakiyuii  
       2021-07-14 12:46:45 +08:00 via iPhone   ❤️ 2
    都是伪需求,一页 100 条也得 7w 页,你会去看第 6w 页的数据嘛?
    ReysC
        5
    ReysC  
       2021-07-14 13:01:48 +08:00   ❤️ 1
    问下,你要速度不低于 1s 的意思,是查询返回时间要超过 1s 吗?
    Thinklong
        6
    Thinklong  
       2021-07-14 13:12:24 +08:00   ❤️ 5
    想要超过 1s 还真挺难的
    dzdh
        7
    dzdh  
       2021-07-14 13:18:04 +08:00
    pk 有序 uuid 或自增 id

    列表限死 100 页

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


    哪个产品说要看第 101 页的就地拍死
    jier17cm
        8
    jier17cm  
       2021-07-14 14:45:05 +08:00   ❤️ 1
    不低于 1s 还有这么无理取闹的要求吗?
    pcbl
        9
    pcbl  
       2021-07-14 15:05:38 +08:00 via Android   ❤️ 3
    不如来个 3 秒钟的加载动画,就像苹果手机一样,老板会觉得搜索很丝滑,一点都不卡
    dingdangnao
        10
    dingdangnao  
       2021-07-14 15:12:12 +08:00
    滚动加载 + 翻页 ?
    encro
        11
    encro  
       2021-07-14 15:16:00 +08:00
    有一个老业务,阿里云 RDS2 核 4G 有一个表,2 亿数据条数据(主要业务非日志),一直没空改,大概页面平均相应时间 200MS 内吧。

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

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

    如果时第一种场景,楼上有答案:1,不要 count ; 2,不然看超过 1000 页的。百度贴吧都是这样的。
    encro
        12
    encro  
       2021-07-14 15:18:28 +08:00
    现在贴吧改进了,直接可以到最后一页了,估计技术改进了。
    wangsongyan
        13
    wangsongyan  
       2021-07-14 15:57:31 +08:00
    其实我对低于 1s 的方案更感兴趣
    robinchina
        14
    robinchina  
       2021-07-14 17:20:11 +08:00
    @encro 昨天看贴吧,点 1000 多页,显示的是当天的····很奇怪的问题
    hejw19970413
        15
    hejw19970413  
       2021-07-14 17:34:32 +08:00
    告诉产品 这个需求不做。
    supermoonie
        16
    supermoonie  
       2021-07-14 17:41:45 +08:00
    线上 mysql 数据库 13626210 条数据,select * from Table order by id desc limit 1000, 100; ( id 是主键),查询想超过 1s 很难
    encro
        17
    encro  
       2021-07-14 17:57:32 +08:00
    @supermoonie


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

    就会慢了。
    pcbl
        18
    pcbl  
       2021-07-14 19:26:21 +08:00 via Android
    @supermoonie 试试楼上说的,limit 越深性能下降越厉害
    supermoonie
        19
    supermoonie  
       2021-07-14 19:33:12 +08:00 via iPhone
    @encro 我明天试试
    supermoonie
        20
    supermoonie  
       2021-07-14 19:33:23 +08:00 via iPhone
    @pcbl 明天
    akira
        21
    akira  
       2021-07-14 20:59:44 +08:00
    分页查询在大数据量,多种复合条件查询 的时候 , 确实都比较麻烦 ,没有什么太好的办法
    emeab
        22
    emeab  
       2021-07-14 21:01:08 +08:00
    700W 真的不带条件查询的吗..
    LING97
        23
    LING97  
       2021-07-14 23:49:16 +08:00
    我们是 40 亿条数据,不过查询用的 es,速度远小于 1 秒,而且大数据的分页这个需求有点没必要把,肯定要带条件。就像上面那个老哥说的,谁会去看第 6w 页的数据。
    young1lin
        24
    young1lin  
       2021-07-14 23:53:27 +08:00
    我用 HBase,几亿数据(浙江农业银行),分页也是秒返回。根据不同业务,将 RowKey 拼接好就行了,上 Es 表也是可以的。
    yagamil
        25
    yagamil  
       2021-07-15 07:50:05 +08:00   ❤️ 1
    做那么多分页,人是不会去看 100 页后面的了, 反而给了机会给那些爬虫的程序,分分钟拖垮你数据库.
    要么是有查询条件.
    huang119412
        26
    huang119412  
       2021-07-15 08:53:37 +08:00
    使用内存数据库,或者傲腾 p5800X 级别固态。
    wowbaby
        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 估计就是这么个理
    wowbaby
        28
    wowbaby  
       2021-07-15 09:20:00 +08:00
    加条件估计做不到吧,上 elasticsearch
    ZeroDu
        29
    ZeroDu  
       2021-07-15 09:25:34 +08:00
    HBase 直接干,TB 级别
    linbiaye
        30
    linbiaye  
       2021-07-15 09:33:35 +08:00
    一般都是通过自增 id 解决,搜索条件带上 id
    ebony0319
        31
    ebony0319  
       2021-07-15 09:37:26 +08:00
    700W 如果只是单表查询感觉还是比较 ok.
    分页查询主要查了两次 第一次查 count(1),第二次具体分页,大数据可以采用 more 的策略,比如你要查 20 条的数据,你可以查 21 条,返回 20 条,然后告诉前端还有更多,这样就节省一次 count 查询.
    ruanimal
        32
    ruanimal  
       2021-07-15 10:06:15 +08:00
    @3dwelcome leveldb 能分页??
    echoZero
        33
    echoZero  
       2021-07-15 10:12:25 +08:00
    如果底层使用 mysql 不变的情况,可以采用瀑布流的,使用最大 id 来查询分页,这样效率不会低
    xiaowei7777
        34
    xiaowei7777  
       2021-07-15 10:26:25 +08:00
    用 es 吧
    pkwenda
        35
    pkwenda  
       2021-07-15 10:32:09 +08:00
    @xiaowei7777 #34 es 也不行,es 只能考虑游标,且 es 默认限制只能 Limit 10000
    KouShuiYu
        36
    KouShuiYu  
       2021-07-15 10:32:20 +08:00
    加上索引,去掉 order,
    wangyzj
        37
    wangyzj  
       2021-07-15 10:35:02 +08:00
    别用 limit
    用 where id>
    或者 redis zset 分页
    leqoqo
        38
    leqoqo  
       2021-07-15 10:40:18 +08:00
    QQ 群关系数据库 几十亿条数据 group 是按 qq 号分的表 QQ 号 /100000 向下取整 为一张表 这样你通过 QQ 号查找 动态拼接表名 就能缩小范围
    3dwelcome
        39
    3dwelcome  
       2021-07-15 11:32:32 +08:00
    @ruanimal " leveldb 能分页??"

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

    主要是 key-value 数据库查询快啊。
    zhouyou457
        40
    zhouyou457  
       2021-07-15 11:36:13 +08:00
    用 mysql 做过亿级订单数据分页,先用订单时间做数据库分区检索再做分页,结果效果一般,特别是碰到跨区的时候。。更别说加上一些复杂的筛选条件了。。

    最后在掐死产品之前,把订单数据迁移到了 Hbase 。。
    v2hh
        41
    v2hh  
       2021-07-15 11:48:21 +08:00
    生产一千多万的数据,查询时间在 500 ~ 800ms, 合理利用索引,干掉复杂查询
    tonghuashuai
        42
    tonghuashuai  
       2021-07-15 13:11:02 +08:00
    不用 limit 使用 ID 做 cursor
    byte10
        43
    byte10  
       2021-07-15 15:09:14 +08:00
    评论少了一个方案。
    1 、首先你单表做查询完全不是问题,有索引足够快了,每次查询带上上一次的索引值即可。
    2 、但是如果你想看到好几万页的数据怎么办?这个其实就是 mongodb 那种分布式数据库的 分页方案了,你创建一个新的表去维护这个大表的分页 ID 就可以了(如果数据经常写入和删除的话,这维护的成本还是挺高的,适合读多写少的),完全不是问题。
    3 、其他的答案就是 ES,HBase 这种数据库作为首选,或者备份。
    yagamil
        44
    yagamil  
       2021-07-15 15:49:50 +08:00
    用 es limit 也不是后面会越来越慢的吗?
    用 id 作为条件分页 应该还好吧
    liuyx7894
        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
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1191 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 39ms · UTC 23:11 · PVG 07:11 · LAX 16:11 · JFK 19:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.