记一次线上的查询 Out of Memory问题 | java.sql.SQLexception:Out of memory | eq_range_index_dive_limit

 最近遇到一个问题，查询数据报错，前端直接不显示数据。用Arthas监控日志，发现是后台查询语句报的错，Caused by: java.sql.SQLexception: Out of memory
why？

 后台抓了下sql语句，好家伙，in后面有10000+，怪不得MySQL扛不住，这搁谁能扛住。
 既然定位了错误位置，接下来就开始改呗，SQL报的OOM，那咱就一次少查点，给MySQL少点压力，分批查询最后再把结果汇总下就OK。
修改前代码：

public List<AuxiliaryVO> getByIds(List<String> ids) {
	 // 注意这里的buildInSql中是拼接了in(?,?,?) 这样的条件，这里查询是直接把10000+个ids全丢进去
     return pubDAOService.query(AuxiliaryVO.class, buildInSql("id",ids), ids.toArray());
}

修改后代码：

public List<AuxiliaryVO> getByIds(List<String> ids) {
        // 分批查询
        List<List<String>> partition = Lists.partition(ids, 500);
        List<AuxiliaryVO> res = new ArrayList<>();
        for(List<String> idsItem : partition){
            res.addAll(pubDAOService.query(AuxiliaryVO.class, buildInSql("id",idsItem), idsItem.toArray()));
        }
        return res;
}

 注意，这里分批查询的batch设置的是500，主要是考虑到了eq_range_index_dive_limit这个参数。
 当使用in条件查询的时候，MySQL优化器会根据eq_range_index_dive_limit这个参数来确定不同的扫描策略。当in中的元素数量小于该参数的值时，优化器使用index dives（索引下潜）的方式评估符合条件的行数；当大于等于该参数的值时，优化器会使用index statistics（索引统计）的方式评估符合条件的行数。特别的，当这个参数是0的时候，优化器使用index dives方式。
 其中，index dives的方式执行策略比较耗时，它会实际读取索引来获取统计信息，但是这种方式比较准确。而index statistics的方式是指，MySQL会定期收集和存储索引的统计信息，优化器在需要的时候直接使用这些存储的统计信息。速度快，但是估计可能不准。当然，评估的行数会最终导致执行计划走不走索引。
 我们线上配置的eq_range_index_dive_limit这个参数是600，我们这设置的500是比较合理的。

show variables like 'eq_range_index_dive_limit';

 这样就可以解决啦！