当前位置:   article > 正文

java查询结果数据量过大_java查询数据库表数据量很大

java查询数据库表数据量很大

场景:

从db中查询数据,并根据查询的结果去构造参数,然后去更新另一张表。由于一次性查询出的结果量过大,很有可能造成OOM

解决办法:

采用mybais流式查询

废话不多说,先上完成后的代码:

Service层

  1. @Service
  2. @Slf4j
  3. public class MarcInstanceServiceImpl implements MarcInstanceService {
  4. @Autowired
  5. private MarcInstanceDao marcInstanceDao;
  6. @Autowired
  7. private InstanceInfoDao instanceInfoDao;
  8. /**
  9. * 重新生成other_title
  10. */
  11. @Override
  12. @Transactional(rollbackFor = Exception.class)
  13. public Integer rebuildOtherTitle() throws IOException {
  14. AtomicInteger count = new AtomicInteger(0);
  15. try (Cursor<MarcInstanceEntity> cursor = marcInstanceDao.getRepeat517Marc()) {
  16. cursor.forEach(marcInstanceEntity -> {
  17. // 构造参数
  18. // 省略。。。
  19. // 去做更新表操作
  20. count.addAndGet(instanceInfoDao.updateOtherTitleById(marcInstanceEntity));
  21. log.info("更新第{}条other_title", count.get());
  22. });
  23. }
  24. log.info("总共更新{}条other_title", count.get());
  25. return count.get();
  26. }
  27. }

其中:

1)marcInstanceDao.getRepeat517Marc()会做大数据量的查询,大概几十万左右。

2)count.addAndGet是计数使用。

3)instanceInfoDao.updateOtherTitleById是根据查询到的结果去更新表。

经过少量数据测试,没有问题。

// todo 进行大批量的数据测试,有结果后会更新到这儿。。。

2022-05-18更新:

经过测试,不到11万的数据量,用时大概3分钟左右,正常结束。

2022-05-20更新:

生产环境OOM了。。。我真是个傻狗。

事情经过:接口如上所写,然后启动给了1024M内存,调用接口,结果OOM。然后重新给2048M,调用接口,还是OOM。最后不限制内存了才能正常调用。

所有这个流式查询并没有解决OOM的问题,原因大概猜到了,应该是:marcInstanceDao.getRepeat517Marc()过大导致的。

综上:这种流式查询并不能解决可能出现OOM的问题。后续待优化。。。

参考:

https://blog.csdn.net/pastxu/article/details/124338586

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/422372
推荐阅读
相关标签
  

闽ICP备14008679号