不走索引的情况及一些规避方案

通过一些日常的开发经验，归纳了一些不走索引的常规情况，欢迎大家补充或指正。

在字符集不一致的时候，不走索引。

如果两个关联表的字符集不一致，会导致索引失效，因此，在生产环境执行DDL建表语句时，要注意不要指定某表或某字段（尤其是关联字段）的字符集，让整个数据库的字符集一致，这样可以避免因字符集导致索引失效的慢sql的问题。

在字段类型不一致的时候，不走索引。

如果有两个关联键字段类型不一致的时候，会导致索引失效。因此在执行创建关联键字段时候，一定要确定另一张表的关联键字段类型是什么。

在字段值过少的时候，不走索引。

如果字段值的选择过少，不便于分辨，比如性别字段，B+树的结构就无法快速检索到你需要的数据，数据库会进行优化，有时会不走索引。

在左模糊查询的时候，不走索引。

在进行条件查询的时候，如果需要对某字段进行模糊查询，请注意，左模糊查询（%在左边）会导致索引失效。因此在开发过程中需要尽量避免这类情况发生。
如果必须要求模糊查询的场景，需要考虑通过其他方式避免这个问题：

1. 通过业务手段避免，举个实际栗子，博主之前做了一个汽车仓储项目，需求要求汽车表查询时候，车架号要有模糊查询操作，但是实际上对于车架号这个东西有个特殊的业务属性，就是车架号的后六位，基本可以在全省锁定到某一台车，全国不会超过三台车。所以业务人员在实际使用系统的时候，也只是输入后六位进行模糊查询，因此，在表设计的时候就将车架号字段冗余了一个字段，用于存储倒序的车架号，在进行模糊查询的时候，使用这个倒序字段进行右模糊查询，从而达到走索引的目的。有些时候，通过业务手段是可以达到一个优化要求的。
2. 通过其他中间件避免，可以考虑将数据同时落到ES一份，查询时候直接查es即可。

在不符合最左前缀原则的时候，不走索引。

在使用联合索引的时候，不符合最左前缀原则的时候，不走索引。

in关键字元素过多的时候，不走索引

B+树的结构导致在进行in查询时，需要多次检索索引树，如果in的元素过多，会导致树的检索次数过多，从而引擎会优化这种操作，更改为全表扫描。因此，一般在使用in关键字的时候，我们只需要空值in的数量就可以避免不走索引的情况，建议在in查询时候在代码中切割参数数组，切割成50条/次的频率来进行in查询即可解决这个问题。