关于hibernate的n+1问题以及解决办法

hibernate的n+1问题已经是一个很常见的问题了。

最近遇到了很多次的n+1问题，总结一下解决办法：

1.ManyToOne中的n+1:

   当查询单个的时候，可以使用来进行让其join查询，

   觉得manyToOne的n+1问题同样可以使用这种方法，其中FetchMode有三个参数：

   

public enum FetchMode {
    /**
     * use a select for each individual entity, collection, or join load.
         * 产生n+1的查询，每个都生成一条查询语句
         * n+1条查询
     */
    SELECT,
    /**
     * use an outer join to load the related entities, collections or joins.
         * 使用一条outer join进行查询
         * 1条查询
     */
    JOIN,
    /**
     * use a subselect query to load the additional collections.
         * 使用一条查询list语句进行查询
         * 2条查询
     */
    SUBSELECT
}

 

    2.查询主体为list的时候的查询

       上面的办法应该是可以解决n+1，但是在查询主表的列表是竟然发现还是会产生多一条语句的情况，于是经过百般查找，找到了一种通过hql来解决此问题的方法：

    

@Entity
@Table(name = "xxxx")
public class ShowInfoEntity implements Serializable {
    private static final long serialVersionUID = -5078958740245381213L;

    // id
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;

    

    // numapi 
    @OneToOne(fetch = FetchType.EAGER, optional = false, mappedBy = "showInfo")
    @Fetch(FetchMode.JOIN)
    private ShowNumber numapi;

 首先这个是主表，其中与从表ShowNumber有一个关联关系，此关联关系是定义在从表中的。

看到这个类上有配置@Fetch 其在查询单个ShowInfoEntity时是能完美的起作用的，即是join查询，但是在查询List<ShowInfoEntity>时就没有这么幸运了，

会先查询一个List<ShowInfoEntity>  之后在查询n条numapi，

使用left join语句也不能解决问题，

最后找到了left join fetch：

@Query("select t from ShowInfoEntity t LEFT join fetch t.numapi r  where t.enable =0 and t.accountId in (?1) and t.timeline<?2")
List<ShowInfoEntity> findByFlush(List<Long> toUsersPredicate, Long time, Pageable page);

顺便说一句，hibernate 的hql语句中的join挺麻烦的，需要先配置好关联关系，然后join 主表.从表

列举一下hql中的join连接

1。左外连接 
     左外连接(Left Outer Join)查询出左表对应的复合条件的所有记录

2.左外抓取连接 
     左外抓取连接指定在Hibernate检索数据时，采用抓取的方式，直接将数据加载到与主表对象关联的从表属性中。

3.右外连接 
    HQL中使用关键字right outer join右外连接

4.内连接

　　内连接（Inner Join）是指两个表中指定的关键字相等的值才会出现在结果集中的一种查询方式。HQL中使用关键字inner join进行内连接，

5.抓取内连接  　　

　　抓取内连接与内连接不同之处在于其对象的内存状态不一样。HQL中使用inner join fetch进行抓取内连接。  

 

 

转载于:https://www.cnblogs.com/lic309/p/5032855.html