1全职匹配我最爱

是指 where 条件里 都是  = ，不是范围（比如＞,＜），不是 不等于，不是 is not null，然后 这几个字段 建立了联合索引 ，而且符合最左原则。

那么就要比 只建立了where条件里 单独的几个索引 查询起来要快。

2 最左匹配

就是where查询条件里 得 有 按照建立联合索引里的字段来，一旦没有最左 就没法走索引！一旦跳过某个字段，后面的索引也没法使用（会影响 key_len ）。

比如 a,b,c 三个字段联合索引。如果where 里有 a,c ，跳过了b，那么虽然sql 可以走 索引，但是 (key_len)长度只有 a 的长度。

3 主键插入

4 计算 函数 导致索引失效 。

5类型转化

 比如 那个字段是varchar 但是你写了数字 ，就会导致类型转化，然后导致索引失效。

int 4 个字节 为null +1 ，5 （表现在key_len上）

varchar 20 长度 * 3， 可为 null +1，可变 再  +2， key_len是 63 。

(如果长度 是 100，就 * 100）

6 范围条件右边的列索引失效 举例sql：

select sql_no_cache * from student where student.age = 30 and student.name = 'abc' and student.classId > 20;

如果我们建立了联合索引，顺序是 age,classId,name 

那么这个sql，key_len 只能是 age(5)+classID(5)是10 。而 name 的索引 就没有用到。

为什么？因为 classId 是个范围，他右边的 就没法用。

按理来说我的 1 和 2  都应该  和 3 一样，为啥 不一样。。

解决方法... 创建联合索引的时候 把等值的往前（往左放），然后范围的往后面放。（原来如此！）

改完之后：优雅，全都走了索引，而且走得满的索引！key_len 最长 5 + 303 

 7 不等于 导致索引失效。。

所以全值匹配的含金量在增加（不是范围，不是不等于）

8 is null 可以走索引 is not null 无法走索引。。

解决方法：设计表的时候，not null 约束。或者int 设置 0 ，字符类型设置为 “”。

not like 也是无法走索引

9 like 以 通配符 % 开头 

上来就不确定，b+树就没法走，那只能全表扫描

10 or 前后 出现非索引的列，索引失效

这里 key3 是有个索引的 ，key2 没有索引。

如果加是 key2 就不行了，全表扫描了

解决方法：or 两边字段都有索引，然后type 就是 index_merge 

 

 11 数据库和表的字符集要统一

不然涉及转化 也会让索引失效 。都用 utf8mb4