1.在联合索引的场景下，查询条件不满足最左匹配原则。
2.使用了select *。（若字段带出，同时where查询里面有索引，还是有机会走覆盖索引的）
3.索引列涉及运算或函数处理，会导致全表扫描，索引失效。
4.模糊查询时（like语句），模糊匹配的占位符位于条件的首部，导致无法走索引。
5.参数类型与字段类型不匹配，导致类型发生了隐式转换，索引失效。
6.查询条件使用or关键字，其中一个字段没有创建索引，则会导致整个查询语句索引失效； or两边为“>”和“<”范围查询时，索引失效。
7.两列数据做比较，即便两列都创建了索引，索引也会失效。
8.使用 != ,<> ,not like等。
9.查询条件使用is null时正常走索引，使用is not null时，不走索引。反之is not null 正常，使用is null时，不走索引。 （MySQL底层会自动判断，如果全表扫描快，则直接使用全表扫描，不走索引。如果表中该索引列数据绝大多数是非空值，则使用 is not null的时候走索引，使用 is null的时候不走索引（还不如全表扫描快），全表扫描；反之亦然。）
10.查询条件使用not in时，如果是主键则走索引，如果是普通索引，则索引失效； 查询条件使用not exists时，索引失效
11.order by排序字段未被索引覆盖。
12.表中数据量少，全表扫描可能更高效。
13.索引列存在大量的重复值，可能导致优化器选择不走索引。
