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内存分配，适当扩大新生代内存大小，让垃圾数据尽量控制在新生代回收。