如何用一个SQL“搞挂”一个服务模块

 

为了批量获取商品规格信息，寡人写下了如下代码和SQL~

/**
      * 批量获取商品规格信息
      * @Description:
      * @author:Zhixw
      * @date:2017年11月27日下午5:33:32
      * @version:1.0
      * @param item_code
      * @return
      */
     List<Map<String,String>> getAllItemDTinfo(@Param("list") List<Map<String,String>> list);

<select id="getAllItemDTinfo" resultType="java.util.Map">
        select ITEM_CODE,UNIT_CODE,DT_INFO from tunit
        <where>
            <foreach collection="list" item="item" open="(" separator=") or (" close=")">
                item_code = #{item.item_code} and unit_code = #{item.unit_code}
            </foreach>
        </where> 
</select>

然后~  本地自测也没有问题，信心满满的就上去了。。。。。回头想起来，幸好是测试环境。否则不炸了才怪

话说回来，为什么要写这样的SQL呢？原因就是为了优化，之前在for循环中查找商品规格，然后数据量大的时候不行了 ，一个普通的小SQL被执行了几百次。用上面的方式改成批量获取的方式，数据量小的时候也没有问题，当然数据量大的时候，这个批量获取的SQL更加可怕，可以搞挂一个模块的微服务

好端端的微服务

寡人所操作的interaction模块，由绿油油的“UP”状态变成了~大红色的“DOWN”。（抱歉当时忘记截图保存  先那这个凑吧）

然后我们再看看日志：

 

 看日志，好像是连接池获取不到了，然后我们刚开始以为是其他的问题，尝试去解决，发现怎么都不能彻底解决，因为每次这个模块重启或者发布之后，这种现象就消失了，然后运行一段时间之后，老毛病又犯了，

然后感觉应该不是连接池的问题，运行了好几个月一直没有动过，怎么会好端端的突然之间就坏了呢，再仔细看了下日志，其实细心的人会发现日志中已经指出了大概发生问题的地方。所以我果断把调用那SQL的地方注释掉之后，再重新发布之后，一切恢复正常，没有再出毛病了

这个SQL在数据量比较大 的时候，应该会执行的非常缓慢，一直占用着数据库资源，然后模块也就挂了