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

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

  •  1
     
  •   kikione · 141 天前 · 5471 次点击
    这是一个创建于 141 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    第 1 条附言  ·  141 天前
    我傻比了

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

    就是单纯的快。
    Jooooooooo
        3
    Jooooooooo  
       141 天前
    大翻页做不到

    有个妥协方案是带上游标

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

    列表限死 100 页

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


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

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

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

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


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

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

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

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

    最后在掐死产品之前,把订单数据迁移到了 Hbase 。。
    v2hh
        41
    v2hh  
       140 天前
    生产一千多万的数据,查询时间在 500 ~ 800ms, 合理利用索引,干掉复杂查询
    tonghuashuai
        42
    tonghuashuai  
       140 天前
    不用 limit 使用 ID 做 cursor
    byte10
        43
    byte10  
       140 天前
    评论少了一个方案。
    1 、首先你单表做查询完全不是问题,有索引足够快了,每次查询带上上一次的索引值即可。
    2 、但是如果你想看到好几万页的数据怎么办?这个其实就是 mongodb 那种分布式数据库的 分页方案了,你创建一个新的表去维护这个大表的分页 ID 就可以了(如果数据经常写入和删除的话,这维护的成本还是挺高的,适合读多写少的),完全不是问题。
    3 、其他的答案就是 ES,HBase 这种数据库作为首选,或者备份。
    yagamil
        44
    yagamil  
       140 天前
    用 es limit 也不是后面会越来越慢的吗?
    用 id 作为条件分页 应该还好吧
    liuyx7894
        45
    liuyx7894  
       140 天前
    加索引就足够快了,通过 id 来翻页,
    我们单表单库两亿多数据
    select max(id) from xxx; 262992300 条
    select * from xxx where id > 262991800 limit 10;
    通过这种方式来检索 0.041s
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3855 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 01:51 · PVG 09:51 · LAX 17:51 · JFK 20:51
    ♥ Do have faith in what you're doing.