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

以下那种方式处理全量数据性能更佳呢?

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

    EXPLAIN SELECT * FROM api_definition order by id LIMIT 1000,100;

        EXPLAIN SELECT * FROM api_definition WHERE id > '1837ec5e-a216-4ead-854d-4' ORDER BY id LIMIT 100;
        以下那种方式处理全量数据性能更佳呢?
        或者又没更好的方式?
    
    9 条回复    2022-11-30 21:11:09 +08:00
    v2wtf
        1
    v2wtf  
       66 天前
    你这不是分页查询吗?算哪门子的全量?
    hackingwu
        2
    hackingwu  
    OP
       66 天前
    @v2wtf 。。。循环一下。你一般怎么处理全量数据的?
    lmshl
        3
    lmshl  
       66 天前
    我都是用第二个语句,但是不加 limit 直接用 jdbc stream ,控制好每个 fetch size 就行。
    如果需要从崩溃恢复,再加 updateTime > [最后处理的时间]
    agmtopy
        4
    agmtopy  
       66 天前
    你这个 id 是自增的嘛.是的话用 2 稍微好一点
    PythonYXY
        5
    PythonYXY  
       66 天前
    具体使用场景是什么呢?
    james2013
        6
    james2013  
       66 天前
    我采用的是第 1 种方法,从单表上亿数据查询过去 24 小时的数据进行处理
    刚开始分页是 100,到后面分页查询越来越慢
    后来分页改成 500,1000,2000
    最后改成 3000,效果很好...
    liuhuan475
        7
    liuhuan475  
       66 天前
    between and 也可以吧,如果是多台实例,可以把分页的 start id 和 end id 做成任务,通过消息队列分发给别的实例,最后瓶颈可能在数据库的 io 上面
    Maboroshii
        8
    Maboroshii  
       65 天前
    第二种, 第一种分页后面好慢
    noparking188
        9
    noparking188  
       65 天前
    你也不说 id 加索引没有
    加索引且有序,第二种效率可以的,我以前都这样扫全表,单表一千多万没问题
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   实用小工具   ·   1570 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 09:39 · PVG 17:39 · LAX 01:39 · JFK 04:39
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.