栏目分类:
子分类:
返回
名师互学网用户登录
快速导航关闭
当前搜索
当前分类
子分类
实用工具
热门搜索
名师互学网 > IT > 软件开发 > 后端开发 > Java

IN 居然不走索引查询???

Java 更新时间: 发布时间: IT归档 最新发布 模块sitemap 名妆网 法律咨询 聚返吧 英语巴士网 伯小乐 网商动力

IN 居然不走索引查询???

项目场景: MySql数据库操作,IN条件查询对应数据,更新到ES存储。 问题描述: 修改了IN中查询的条件,导致系统fullgc,重启系统之后当触发了该查询条件后,服务器立马又开始不断fullgc,导致服务整体不可用。

IN多条件查询类比如下场景1:

 1. EXPLAIN SELECt * FROM test WHERe client_id  in (0,1,2,3);

 2. EXPLAIN SELECt * FROM test WHERe client_id  in (0);

 3. EXPLAIN SELECt * FROM test WHERe client_id  in (1);

其中全表数据150w,client_id=0数据50w,其他条件数据均为1条,EXPLAIN结果如下:

  1. 场景1sql, 扫描全表,耗时较长;
  2. 场景2sql, 走索引,耗时短;
  3. 场景3sql, 走索引,耗时短。
原因分析: 经过一系列定位和几次重启观察,发现并不是系统发生了内存泄漏,而是由于IN查询语句并没有如预期走索引查询,而是进行了全表扫描。IN条件中当client_id=0时,有50w数据,全部加载到了内存,并且由于全表扫描,查询耗时较长,引发了系统连锁反应,最终导致系统不断进行fullgc,无法正常运行。
解决方案: IN条件究竟是否走索引呢?
  • 通常场景,IN条件查询走索引;
  • 当IN多条件查询时,如果数据量大于总数据量30%,就会走全表扫描(暂未找到官方结论,但在Mysql版本为8.0.18中,本人验证基本符合上述结论);
  • 当IN是单条件,数据量大于总数据30%时,依然走索引。

最后的解决方案是对IN条件查询进行了优化处理,单独查询一次client_id=0对数据,进行Es同步;
优化了JVM内存分配,适当扩大新生代内存大小,让垃圾数据尽量控制在新生代回收。

转载请注明:文章转载自 www.mshxw.com
本文地址:https://www.mshxw.com/it/327801.html
我们一直用心在做
关于我们 文章归档 网站地图 联系我们

版权所有 (c)2021-2022 MSHXW.COM

ICP备案号:晋ICP备2021003244-6号