Spring Data JPA 性能优化之 findAll

2023-12-30 05:32:02

优化场景描述

当时是测试环境,进行一个列表的初始化分页查询,pageSize 为8(已经很小了),页面的数据项也很少,就那么几个信息,但是性能压测通过不了。

提出性能问题假设

事关性能问题,我们不妨大胆的假设:

  • pageSize只有8,会不会是返回的数据包含的信息量太大,网络IO顶不住?
  • 接口会不会有第三方的调用,有等待延迟?
  • 接口内部的查询逻辑会不会过于复杂,需要多表且多次查询?
  • 数据库数据量太大,查询是否命中索引或是否需要索引?
  • 查询的SQL语句是否有不合理需要优化的地方?

按假设逐一排查

1、pageSize只有8,会不会是返回的数据包含的信息量太大,网络IO顶不住?

在查询页面,打开F12,查看接口的返回数据,不难发现返回的List列表里面层层嵌套了不少List列表(案例只嵌套了一层,不过有3个嵌套),且嵌套在内部的数据量还不小。

结论:有可能是信息量太大

2、接口会不会有第三方的调用,有等待延迟?

进入接口内部,没有发现第三方的调用,就不存在等待延迟。

结论:排除可能。

3、接口内部的查询逻辑会不会过于复杂,需要多表且多次查询?

进入接口内部,逻辑很清晰,就是一个单表的分页查询。

结论:排除可能。

4、数据库数据量太大,查询是否命中索引或是否需要索引?

测试环境的数据量算很小了,索引不索引的,不应该是影响性能的主要原因。

结论:排除可能。

5、查询的SQL语句是否有不合理需要优化的地方?

接口采用的Spring Data JPA 的findAll 分页查询,属于JPA的东西,应该不会有太大的性能问题吧。

结论:JPA的findAll 查询有可能有性能问题

那么最有可能的就是1和5了,那就进一步排查。

因为返回值存在List的层层嵌套,而接口又是一个单表查询,这是不是有点矛盾?那么朝矛盾点进发,打开对应的类对象,仔细一看,好家伙,嵌套的List 对象上各自添加了 @OneToMany、@ManyToMany、@ManyToOne 注解,注解让我们查询的表与其他表进行了级联操作。findAll 方法会去查询关联表的信息。3个级联关系,再查询3次SQL,性能差距也不能这么差吧。于是我再去看findAll 方法执行时的日志,不看不知道,一看吓一跳。findAll 方法执行了很多次的查询,经我观察发现,关联表相关的数据量越大,查询的次数就越多(根源问题找到了:SQL的多次执行)。

结论:因为对象的级联关系,导致 findAll 会自动查询关联表(多次查询)的信息并进行数据封装,导致数据库压力大,造成性能问题。

优化分析

  • 从业务需求方面:
    是否需要级联查询的关联数据,如果不需要,去掉级联查询。

  • 从网络IO方面:
    返回的冗余数据量过多,需要剔除冗余数据量。

  • 从SQL方面:
    发现findAll 方法会因为关联数据增多,而新增查询语句,导致多次查询。因此决定自行写SQL。

  • 从缓存方面:
    如果没有冗余数据,也采用了SQL优化的方法,但还是慢,则要考虑redis缓存了。

解决措施

  • 从业务需求方面:
    List的嵌套数据确实是多余的,可以去掉级联查询到的多余List。

  • 从网络IO方面:
    返回值对象重新封装一下,只返回需要返回的数据。

  • 从SQL方面:(分页查询返回的Page)
    采用 nativeQuery = true 自行编写sql的方式,但是不能返回 Page,这样会触发级联查询。因此用 Page<Map<String, Object>> 对象接受查询的返回值(跟踪日志发现,接口查询只进行了一次SQL查询),并做map 的List处理, 用JSON.parseArray(JSON.toJSONString(List对象), 类对象名.class) 处理得到想要的List对象。

小结:当类对象存在 @OneToMany、@ManyToMany、@ManyToOne 等注解时,要特别注意,findAll(@Nullable Specification var1, Pageable var2) 返回的 Page< T > 会自行进行级联查询并数据封装。使用自定义的查询(nativeQuery = true)并返回 Page<Map<String, Object>> 对象就可以避免级联查询。

文章来源:https://blog.csdn.net/glb168/article/details/135292554
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。