实际应用：one-to-many，fetch最好不要设置多个join

最近美国customer报了个问题，1条huge数据 （2个1000子数据）读取 java map out of memory.
分析了下原因，
A 表 onetomany B
A 表 onetomany C
A 表 onetoone D

读取A的一条数据 大约包含1000个B， 1000个C， 读取的时候就内存溢出了。
看了下log，发现读取的SQL： A left join B left join C leftjoin D,
返回 700，000条结果，这就是问题所在了。。。
这几个表每个表都 20+个column，再好的服务器也溢出了。

看了下A.hbm.xml， B 和 C 和 D都是 fetch=join.
fetch设置join， lazy只能是false。

分析下逻辑 1000个C 的访问性需求没1000个B高， 将C设置为fetch=select。
然后运行下，这次log里 原先sql 变为两个
A left join B leftjoin D，
select C，

发过去让customer 测试了下，好像可以了，这个问题暂时解决了。
one-to-many，fetch最好不要设置多个join，最常用的设为join。
如果设置个四五个，即使是一般不是很大的数据，结果数目 100x 100 X 100 X100还是很可怕的结果。


这样huge的数据，觉得还有问题，依次访问1000个B或C的关联对象 M或N时候 每访问一个会调用依次sql，
1000次的sql花费时间肯定不少。好在调用非PK属性时候才会调用SQL