条件一:查询的结果集,超过了总行数 25%,优化器就会认为没有必要走索引了。
引自:
条件二:回表查询可能会导致优化器认为不走索引的效率更高。回表即无法使用覆盖索引(查询的字段并不是全部在索引的列中),需要根据索引查询的字段(可能是主键,有待查证)再去表中去取数据。
引自:
技术分享 | 为什么 SELECT 查询选择全表扫描,而不走索引?_ActionTech的博客-CSDN博客_select不走索引
相关资源:
like百分号加前面一定不走索引吗?一不小心就翻车,关于mysql索引那些容易错的点_Hesse77的博客-CSDN博客
索引的失效场景:
①联合索引不满足最左匹配原则(前提是不走优化器,优化器会优化这类sql语句)。即建立的索引与 where 语句中查询的条件顺序不一致。
②索引列参与运算、索引列参使用了函数、类型隐式转换。
③错误的 like 使用。例如%放在了字符串的前面,是很可能不走索引的,除非是覆盖索引。如果范围查询过后的a是个确定值,那后面还是走索引的,否则不走。
④or字段不走索引。特例,多个or字段是同一个字段,只是条件不同。
⑤两列数据做比较,即便两列都创建了索引,索引也会失效。
⑥不等于比较可能导致索引失效。当查询结果集占比比较小时,会走索引,占比比较大时不会走索引。此处与结果集与总体的占比有关。
⑦查询条件使用is null时正常走索引,使用is not null时,不走索引。
⑧not in(除主键外)会索引失效。
⑨not exists索引失效。
⑩order by导致(除主键外)索引失效。可能和版本有关系。
另外:select *可能导致不走索引,由于回表的发生,使得优化器认为不走索引会效率更高。尽量写明查询字段。