说起这次事故就感觉让人无语,最近招了个新人,感觉做事也还行,但是最后还是败在小问题上。
先可以看看下面这段代码:
<select id="selectListById" resultType="com.order.OrderDTO">
select distinct
t1.ID orderId,
t3.approle as appRole,
t3.LEGALNAME as legalName,
t3.LEGALTEL legaltel,
t3.LEGALIDNO legalidNo,
t3.holder_name ,
t3.holder_id,
t3.holder_mobile,
t3.MOBILE mobile,
t1.apply_ip
from
t_apply t1
left join t_material t3 on t1.ID = t3.APPLY_ID
left join t_user u on t1.CUST_ID = u.USER_ID
where t1.ENABLE = 1
<if test="param.productCodes.size() >0">
and t1.ID in
<foreach collection="productCodes" open="(" separator="," close=")" item="item">
#{item}
</foreach>
</if>
</select>
看了上面的代码,问题出在哪呢?没错 if test=“param.productCodes.size() >0”>,就这。数据库 t_apply表有近300W的数据,当这个条件不成立的时候就会查询全表,把全部数据都查出来,如果多几次查询就导致内存溢出。最关键的是在查询数据后还会循环处理业务,导致内存一直不释放,最终的结果可想而知。
文章讲述了由于新入职员工编写的SQL查询代码中一个条件判断错误,当条件不满足时导致全表查询,对于包含近300万数据的表,这引发了内存溢出。尤其是在后续处理中,循环业务操作使得内存无法释放,加剧了问题的严重性。
937

被折叠的 条评论
为什么被折叠?



