最近美国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
分析了下原因,
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