9) hibernate.batch_fetch_style:

该配置是hibernate4.2.0新添加的，使用这个设置可以配置hibernate在做batch-fetch的时候，生成SQL的策略。该配置项的可选值为org.hibernate.loader.BatchFetchStyle这个枚举类型中的可选值。所以，目前有三个选项：LEGACY，PADDED和DYNAMIC。下面分别介绍：

1，LEGACY：该批量抓取样式从一个预定义的数组中获取指定的匹配的个数来包装in后面的问号的个数，这个预定义的数组由org.hibernate.internal.util.collections.ArrayHelper#getBatchSizes 方法得到的。LEGACY也是该配置项的默认值。举一个简单的例子，假如向数据表中插入39条数据：

@Before
public void save() {
for (int i = 0; i < 39; i++) {
Department d = new Department();
d.setName("d" + i);
Employee e=new Employee();
e.setName("e"+i);
e.setDept(d);
Session session = HibernateUtil.getInstance().getSession();
session.beginTransaction();
session.save(d);
session.save(e);
session.getTransaction().commit();
session.close();
}
}

如果要批量获取，batch-fetch大小设置为14：

@Test
public void testBatchFetch() {
Session session = HibernateUtil.getInstance().getSession();
List emps = session.createQuery("FROM Employee").list();
for (Employee emp : emps) {
System.out.printf("employee:%s belong %s department \r\n",
emp.getId(), emp.getDept().getName());
}
session.close();
}

得到所有的Employee，并遍历访问Employee对应的Department，批量大小设置为14：

<class name="Department" batch-size="14">
<id name="id">
<generator class="native" />
</id>
<property name="name" />
<set name="emps">
<key column="DEPT_ID"/>
<one-to-many class="Employee"/>
</set>
</class>

在hibernate.properties文件中配置：

hibernate.batch_fetch_style LEGACY

运行测试，输出内容（简化之后）：

Hibernate: select employee0_.id as id1_1_, employee0_.name as name2_1_, employee0_.DEPT_ID as DEPT3_1_ from Employee employee0_

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:1 到 employee:14

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:15 到 employee:28

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:28 到 employee:38

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id=?

employee:39

可以很清楚的看出，在连续使用14批量拿了两次数据之后，并没有直接把最后一个批量的数据（11个）一次性的拿出来，而是分别使用了10+1的方式分了两次拿到数据。原理分析如下：

首先根据设置的batch-size=14，把14作为最大的batch数传给org.hibernate.internal.util.collections.ArrayHelper#getBatchSizes方法，得到一个预处理的数组为：[14,10,9,8,7,6,5,4,3,2,1]，换句话说，能够放到IN后面的批量的数字只能是这个数组中的某一个值，所以，第一次取，39>14，取最大批量14，第二次取，25>14，取最大批量14，第三次取11<14，所以只能取第二大的11>10，取10批量，最后一次取，取1个。这种策略就很清晰了。

2，PADDED：该方式和LEGACY一样，从一个预定义的数组中获取指定的匹配的个数来包装in后面的问号的个数，这个预定义的数组由org.hibernate.internal.util.collections.ArrayHelper#getBatchSizes 方法得到的。和LEGACY不同的是，当余下的数量不够的时候，该方式总会选择一个大于当前匹配批量的数量。相同的示例，我们修改批量样式为：

hibernate.batch_fetch_style PADDED

运行测试，控制台输出（简化之后):

Hibernate: select employee0_.id as id1_1_, employee0_.name as name2_1_, employee0_.DEPT_ID as DEPT3_1_ from Employee employee0_

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:1 到employee:14

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:15 到employee:28

Hibernate: select department0_.id as id1_0_0_, department0_.name as name2_0_0_ from Department department0_ where department0_.id in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

employee:29 到employee:39

可以清楚的看出PADDED和LEGACY的区别，PADDED只使用了3次批量就取出了所有的数据，取值流程为：

首先根据设置的batch-size=14，把14作为最大的batch数传给org.hibernate.internal.util.collections.ArrayHelper#getBatchSizes方法，得到一个预处理的数组为：[14,10,9,8,7,6,5,4,3,2,1]，换句话说，能够放到IN后面的批量的数字只能是这个数组中的某一个值，所以，第一次取，39>14，取最大批量14，第二次取，25>14，取最大批量14，第三次取11<14，但是，PADDED会选择比10大1的数量，即选中14，然后用14把剩下的11个对象一次性的取出来了。

3，DYNAMIC：有多少数量，就直接使用一个批次全部拿出来，但是，还是不能超过设置的batch-size。所以，很好理解，如果使用DYNAMIC，也会使用14+14+14的方式分3次批量的把数据查询出来。

最后，可能有同学觉得使用PADDED+更大的batch-size就行了，其实也不是这样，因为毕竟是批量的去获取关联的数据，如果关联的数据过大，特别是批量的获取集合数据，得到的结果集越大，性能也会慢下来，所以，根据具体的应用需求合理的设置批量SQL样式和批量大小也是需要慎重考虑的。