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; 以下那种方式处理全量数据性能更佳呢? 或者又没更好的方式?
![]() | 1 v2wtf 2022-11-30 12:13:47 +08:00 你这不是分页查询吗?算哪门子的全量? |
3 lmshl 2022-11-30 14:25:53 +08:00 我都是用第二个语句,但是不加 limit 直接用 jdbc stream ,控制好每个 fetch size 就行。 如果需要从崩溃恢复,再加 updateTime > [最后处理的时间] |
4 agmtopy 2022-11-30 14:33:11 +08:00 你这个 id 是自增的嘛.是的话用 2 稍微好一点 |
5 PythonYXY 2022-11-30 14:48:41 +08:00 具体使用场景是什么呢? |
![]() | 6 james2013 2022-11-30 15:02:30 +08:00 我采用的是第 1 种方法,从单表上亿数据查询过去 24 小时的数据进行处理 刚开始分页是 100,到后面分页查询越来越慢 后来分页改成 500,1000,2000 最后改成 3000,效果很好... |
7 liuhuan475 2022-11-30 17:26:04 +08:00 between and 也可以吧,如果是多台实例,可以把分页的 start id 和 end id 做成任务,通过消息队列分发给别的实例,最后瓶颈可能在数据库的 io 上面 |
![]() | 8 Maboroshii 2022-11-30 20:26:38 +08:00 第二种, 第一种分页后面好慢 |
![]() | 9 noparking188 2022-11-30 21:11:09 +08:00 你也不说 id 加索引没有 加索引且有序,第二种效率可以的,我以前都这样扫全表,单表一千多万没问题 |