优化场景描述

当时是测试环境，进行一个列表的初始化分页查询，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>> 对象就可以避免级联查询。