【JPA】记录JPA批量处理的优化

【JPA】记录JPA批量处理的优化,第1张

【JPA】记录JPA批量处理的优化

在jpa的使用过程中,发现用jpa内置的deleteAll()方法和saveAll()方法,效率都有所不足。看了下它调用的sql语句,发现删除是根据id一条条的删除,批量保存也是逐条先查后存,感觉明显是这个影响了运行速度。

根据id逐条删除

若是部分批量删除还可以理解,但是当想要整表数据删除时,就显得效率不足。而且delete后,数据库中的空间不会得到释放,后续查询也还是性能较差。

逐条保存且每次都要做一个查询

网上看了看有没有大佬有合适的优化方法,大致还是通过原生sql的形式优化处理。

@Repository
public interface AllDeviceRepository extends JpaRepository {

    @Transactional
    @Modifying
    @Query(value = "truncate table all_device_info",nativeQuery = true)
    void truncateTable();
}

删除效率有明显提升。

可以看到直接执行这条原生sql,速度明显提升,且释放了空间。注意:truncate table有因为权限或锁竞争的风险而导致一直堵塞住运行不下去。此时可以尝试换delete table的原生sql。

然后就是批量新增。自增主键id的策略模式会导致先查询后插入的情况。所以如果也无需求对表id没有什么要求的话,使用uuid的主键帮助会更大。

@Data
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class baseDO {

    @Id
    @GenericGenerator(name = "id-generator", strategy = "uuid")
    @GeneratedValue(generator = "id-generator")
    protected String pid;

    @CreatedDate
    private Date createTime;

    @LastModifiedDate
    private Date updateTime;

}

 修改后再运行一遍,可以发现不会在进行先查后插的形式进行批量插入了。

 当然,插入前查询对一些业务场景也是很有帮助的。这里主要针对的是追求批量新增时的效率问题,提高性能。

 

 

 

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5636661.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-16
下一篇 2022-12-16

发表评论

登录后才能评论

评论列表(0条)

保存