测试发现 fetch="join" 和 fetch="select" 没区别？

在hibernate3里面多了 fetch的选项，文档里面说得很简单，我知道lazy参数才是决定是否在查询主表的时候去查询子表，但是这个 fetch又起什么作用呢？我测试了一下，发现无论是 fetch="join" 还是 fetch="select",hibernate向数据库发送的 SQL都是一样的。 以一个简单的一对多做例子：
Many 一端

<hibernate-mapping>
    <class name="lyo.test.hibernate.bean.PostThread" table="thread" catalog="testrails">
        <id name="id" type="java.lang.Integer">
            <column name="id" />
            <generator class="native" />
        </id>
<many-to-one name="developer" class="lyo.test.hibernate.bean.Developer"
          lazy="false"  fetch="join">
            <column name="developer_id">
                <comment></comment>
            </column>
        </many-to-one>
    </class>
</hibernate-mapping>

One 一端：

<hibernate-mapping>
    <class name="lyo.test.hibernate.bean.Developer" table="developer" catalog="testrails">
        <id name="id" type="java.lang.Integer">
            <column name="id" />
            <generator class="native" />
        </id>
  <set name="threads" inverse="true" cascade="all">
            <key>
                <column name="developer_id">
                    <comment></comment>
                </column>
            </key>
            <one-to-many class="lyo.test.hibernate.bean.PostThread" />
        </set>
    </class>
</hibernate-mapping>

测试查询语句：

List list=session.createQuery("from PostThread").list();

发现 hibernate向数据库发送的语句都是：

07:45:11,471 DEBUG org.hibernate.hql.ast.QueryTranslatorImpl.generate:217 - SQL: select postthread0_.id as id0_,  postthread0_.developer_id as developer10_0_  from testrails.thread postthread0_

怎么会没有区别呢？ 文档上好像说 join的方式效率高一些，但是是否取子表的数据不是由 lazy参数决定的么，和 fetch 参数有什么关系？

fetch参数指定了关联对象抓取的方式是select查询还是join查询，select方式时先查询返回要查询的主体对象（列表），再根据关联外键id，每一个对象发一个select查询，获取关联的对象，形成n+1次查询；
而join方式，主体对象和关联对象用一句外键关联的sql同时查询出来，不会形成多次查询。
如果你的关联对象是延迟加载的，它当然不会去查询关联对象。
另外，在hql查询中配置文件中设置的join方式是不起作用的（而在所有其他查询方式如get、criteria或再关联获取等等都是有效的），会使用select方式，除非你在hql中指定join fetch某个关联对象。

fetch策略用于定义 get/load一个对象时，如何获取非lazy的对象/集合。  这些参数在Query中无效。

这样说是对的。
刚查阅了hibernate3的文档：
查询抓取（默认的）在N+1查询的情况下是极其脆弱的，因此我们可能会要求在映射文档中定义使用连接抓取：

<set name="permissions"
            fetch="join">
    <key column="userId"/>
    <one-to-many class="Permission"/>
</set
<many-to-one name="mother" class="Cat" fetch="join"/>
在映射文档中定义的抓取策略将会有产生以下影响：

通过get()或load()方法取得数据。

只有在关联之间进行导航时，才会隐式的取得数据(延迟抓取)。

条件查询

在映射文档中显式的声明 连接抓取做为抓取策略并不会影响到随后的HQL查询。

通常情况下，我们并不使用映射文档进行抓取策略的定制。更多的是，保持其默认值，然后在特定的事务中， 使用HQL的左连接抓取（left join fetch） 对其进行重载。这将通知 Hibernate在第一次查询中使用外部关联（outer join），直接得到其关联数据。 在条件查询 API中，应该调用 setFetchMode(FetchMode.JOIN)语句。
http://www.redsaga.com/hibernate-ref/3.x/zh-cn/html/performance.html#performance-fetching-custom

这个说法不全对。在某种特殊的场合下，fetch在hql中还是起作用的。
例如
现有message(回帖)-->topic(主贴)-->forum(版块) 的多级many-to-one结构:
第一级:message-->topic  many-to-one配置lazy="false"  fetch="join"
第二级:topic-->forum    many-to-one配置lazy="false"  fetch="join"
这时如果"from message",则第二级:topic-->forum中的fetch策略会起作用

经验证确实如此，执行from Message总共会跑出1+n条语句：
1、
select message0_.id as id2_, message0_.topic_id as topic2_2_ from Message message0_
2、
select topic0_.id as id1_1_, topic0_.forum_id as forum2_1_1_, forum1_.id as id0_0_ from Topic topic0_, Forum forum1_ where topic0_.forum_id=forum1_.id and topic0_.id=?

其中如果有多个message，总共被n个topic所有，则会有n个第2条语句。

其实这并不能说明hql能够按照配置文件设置的join进行抓取，这时 第二级:topic-->forum 的抓取其实已经和hql没有关系了，因为前面已经产生了另一个select方式的抓取语句。
而是对象的关联获取，假如查询message时topic是设置为延迟加载的，那么在后面获取message.topic时，如topic.forum不延迟加载，那么topic-->forum会实现配置的join方式的抓取，这个显然和hql查询没有关系。