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

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

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

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

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

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

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

    有个妥协方案是带上游标

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

    列表限死 100 页

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


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

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

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

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


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

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

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

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

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