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

[hackingwu]

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;
    以下那种方式处理全量数据性能更佳呢？
    或者又没更好的方式？

[v2wtf]

你这不是分页查询吗？算哪门子的全量？

[hackingwu]

@v2wtf 。。。循环一下。你一般怎么处理全量数据的？

[lmshl]

我都是用第二个语句，但是不加 limit 直接用 jdbc stream ，控制好每个 fetch size 就行。
如果需要从崩溃恢复，再加 updateTime > [最后处理的时间]

[agmtopy]

你这个 id 是自增的嘛.是的话用 2 稍微好一点

[PythonYXY]

具体使用场景是什么呢？

[james2013]

我采用的是第 1 种方法,从单表上亿数据查询过去 24 小时的数据进行处理
刚开始分页是 100,到后面分页查询越来越慢
后来分页改成 500,1000,2000
最后改成 3000,效果很好...

[liuhuan475]

between and 也可以吧，如果是多台实例，可以把分页的 start id 和 end id 做成任务，通过消息队列分发给别的实例，最后瓶颈可能在数据库的 io 上面

[Maboroshii]

第二种, 第一种分页后面好慢

[noparking188]

你也不说 id 加索引没有
加索引且有序，第二种效率可以的，我以前都这样扫全表，单表一千多万没问题