优化Spring-Data JPA查询

  • Z时代
  • 2024-01-10
  • 分类：问答

我正在寻找框架生成的查询的可能的优化。据我了解，该过程如下：

  • 你可以声明你的域对象是POJO和增加几个注解像@Entity，@Table，@ManyToOne等等。

  • 您声明您的存储库，例如每个接口

使用（2），您可以通过多种方式描述您的查询：例如，每个方法名或 @Query

如果我写这样的查询：

@Query("select t from Order t LEFT join fetch t.orderPositions where t.id = ?1")
Page<Order> findById(Pageable pageable, String id);

将自动生成一个SQL查询，其中解析订单的每一列，并随后解析订单位置和相关对象/表。好像我写了：

select * from order

因此，以防万一，我需要来自 多个 连接对象的 一些

信息，查询可能会非常昂贵：并且更有趣的是效率很低。我偶然发现了一个缓慢的查询，MySQL解释说，在 生成的 查询中，优化器无法利用索引，这很不好。

当然（我知道）我必须权衡一个问题，即 生成的 SQL不如 手动 编写的那样理想，并且具有编写更少样板代码的优势。

我的问题是：改善查询，查询执行的好的策略是什么？

我自己考虑过一些选择：

1）是否可以为不同的目的定义多个“实体”，例如Order访问订单的 全部

特征，以​​及FilteredOrder使用更少的列和没有解析度的东西Join-

columns？两者都将引用相同的表，但是一个将使用所有列，而另一个仅使用一些。

2）@Query(...

native="true")选择要使用的所有列。这样做的好处是，我不会将域对象加倍，也不会用数百个Filtered-Object填充我的代码库。那分页呢？使用pageable结合@Query(

...native="true")仍然有可能（恐怕没有）。

3）最后但在我眼中，“最糟糕” /样板的解决方案：JDBCTemplates在较低的水平上使用和做一些事情。

还有其他我没有想到的选择吗？感谢您在该主题上的任何启发：]

我们目前的策略是

1）在可能的情况下，我将与 select new 一起工作

如我所见，它适用于每个Object（无论是

Entity 还是 POJO ）

2）与数据库 视图 结合使用时，可以充分利用 SQL 和 ORM的优势

。对于某些用例，手头有一个聚合结果集可能会很有趣。通过将此结果集定义为视图，可以从数据库角度轻松地通过简单的 select -statement

观察结果。对于ORM端，这意味着您可以轻松定义与该视图匹配的实体，并在顶部获得整个 ORM优点 ：分页包括。

回答：

一种解决方案是使用DTO：

@Query("select new FilteredOrder(o.name, o.size, o.cost) from Order o where o.id = ?1")
Page<FilteredOrder> findFilteredOrderById(Pageable pageable, String id);

如果您想为某些报告生成实体，也许您应该考虑使用nosql数据存储？

以上是 优化Spring-Data JPA查询 的全部内容， 来源链接： utcz.com/qa/417781.html

回到顶部