MySQL--索引失效--原因/解决方案

简介

        本文介绍数据库什么时候会索引失效以及如何避免索引失效。

        这个问题也是Java后端面试中常见的问题。

失效的场景

1. 1. 
      
2. %和_这两个是模糊匹配，如果放在开头则不走索引。

​

1. 当OR 左右查询字段只有一个是索引，该索引失效，只有当OR 左右查询字段均为索引时，才会生效。

2. varchar不加单引号的话可能会自动转换为int型，使索引无效，产生全表扫描。
   例如：tb1表中name字段是字符串类型
3. 
   
   1. 1. 
         
   2. 索引失效：SELECT * FROM tb1 WHERE name = 123
   3. 索引有效：SELECT * FROM tb1 WHERE name = '123'
      1. 
         
4. 
   

1. 1. 
      
2. 原因：索引无法通过空值计算出存储它的位置。
4. 解决方法：
5. 
   
   1. 1. 
         
   2. 法1：把NULL值转为一个特定的值，在WHERE中检索时，用该特定值查找
   3. 法2：建立一个联合索引。例如：create index ind_a on table(col1,1); 通过在复合索引中指定一个非空常量值，而使构成索引的列的组合中，不可能出现全空值。
      1. 
         
6. 
   
   1. 
      

1. 1. 
      
2. 不等操作符永远不会用到索引，对它的处理只会产生全表扫描。
3. 优化方法： key<>0 改为 key>0 OR key<0。
   1. 
      

1. 1. 
      
2. 原因：索引是针对原值建的二叉树，将列值计算后，原来的二叉树就用不上了。
4. 示例：
5. 
   
   1. 1. 
         
   2. SELECT * FROM t WHERE id*3=3000
   3. SELECT * FROM t WHERE ABS(id)=3000
      1. 
         
6. 
   
   1. 
      

1. 1. 
      
2. 此时mysql会使用全表扫描，索引失效。
4. 例如：
5. 
   
   1. 1. 
         
   2. 数据量极少的表
   3. 表中索引字段数据重复率太高
      1. 
         
6. 
   
   1. 
      

1. 1. 
      
2. 可能会导致索引失效，与版本有关。
3. 原因：SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。此语句将进行全表扫描（可能）：SELECT id FROM t WHERE num = @num
4. 解决方案：强制查询使用索引：SELECT id FROM t WITH(INDEX(索引名)) WHERE num = @num
   1. 
      

参考网址​

​​MySQL 索引未命中情况​​​