两种极端情况的案例：N+1次查询和笛卡尔积

前一篇文章两种极端：频繁的查询和巨大的结果集讲到了Hibernate加载数据时可能会出现的两种极端情况：频繁的查询和一次查出巨大的结果集。其中：N+1次查询是前一种情况的一个典型案例，笛卡尔积则是后一种情况的典型案例。下面分别简单地再总结一下这两种极端案例出现的原因以及调优方法。

 

一.N+1次查询

    如果一个集合是lazy loading的,那么在第一次访问到这个集合时，hibernate会生成一个select被这个集合加载出来。这是N+1中的1。紧接着，在迭代这个集合的过程中，如果要访问集合元素所依赖的其他关联对象时，若它的关联对象也是lazy loading的，那么hibernate会生成一个select从数据库中加载出这个关联对象。这样，N次循环就会生成n个select，这就是N+1中的N.

    解决N+1次查询需要在制定动态抓取策略时eager fetch出集合和集合元素的依赖对象，这样只会生成一条SQL。具体做法是在HOL中，使用fetch关键字来抓取所需要的对象。在Criteria中使用setFetchMode方法设置目标抓取对象。具体示例请参考JPwH-13.5.2

 

 

二.笛卡尔积

    N+1次查询的反面就是笛卡尔积。一般来说，通过定制动态抓取策略，不会加载出我们不需要的数据，但是有一种情况下，即使我们只加载必需对象也会造成大量数据被select出来，这就是抓取“平行”集合导致的笛卡尔积。

    例如：一个Forum有一个Moderator集合，大小为3和一个Thread集合，大小为100。如果在加载Forum时，单独抓取Moderator集合，结果集是3，单独抓取Thread集合，结果集是100，同时抓取这两个集合的结果集是两个集合的加乘（也就是笛卡尔积）为：3*100.如果还有第三个集合，大小是50的话，那结果集就会变成3*100*50. 因此我们可以看到：抓取“平行”集合会产生笛卡尔积，如果集合很多或集合中的元素很多，会使结果集急剧的膨胀。一个巨大的结果集所带来的性能损失是什么呢？想想数据库服务器处理这个条数据所花的时间，占用的服务器的内存，通过网络传输这些数据，以即到了应用服务器占用的内存和hibernate封装这些数据所花费的时间，和这些开销相比，分成两三个SQL（会成数量级的减小结果集）来获取数据要快得多得多。

    HIbernate并不禁止我们产生笛卡尔积，也就是说，你可以在一个抓取计划中抓取多个“平行”集合。但是有一个例外，就是bag集合。Hibernate不允许同时抓取两个以上的bag集合。这是因为：The resultset of a product can’t be converted into bag collections, because Hibernate can’t know which rows contain duplicates that are valid (bags allow duplicates) and which aren’t.

    对于“平行”集合的问题，在抓取时要灵活应对，如果预计到结果集会很大，那么就不要使用join fetch，而要使用subselect fetch!subselect fetch是平行集合的推荐优化方案。

    关于N+1次查询和笛卡尔积，请参考JPwH_13.2.5节。