MySQL索引优化原则和失效情况

1. 全值匹配

• 创建表 插入数据

CREATE TABLE users(
  id INT PRIMARY KEY AUTO_INCREMENT,
  user_name VARCHAR(20) NOT NULL COMMENT '姓名',
  user_age INT NOT NULL DEFAULT 0 COMMENT '年龄',
  user_level VARCHAR(20) NOT NULL COMMENT '用户等级',
  reg_time TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '注册时间'
);
INSERT INTO users(user_name,user_age,user_level,reg_time)
VALUES('tom',17,'A',NOW()),('jack',18,'B',NOW()),('lucy',18,'C',NOW());

按索引字段顺序匹配使用。

xxxxxxxxxx
EXPLAIN SELECT * FROM users WHERE user_name = 'tom';
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17
EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17 
AND user_level = 'A';

按顺序使用联合索引时, type类型都是 ref ,使用到了索引 效率比较高

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-L96I1PWu-1688780333046)(.\img\07.jpg)]

2. 最佳左前缀法则

如果创建的是联合索引,就要遵循 最佳左前缀法则: 使用索引时，where后面的条件需要从索引的最左前列开始并且不跳过索引中的列使用。

场景1: 按照索引字段顺序使用，三个字段都使用了索引,没有问题。

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 'tom' 

AND user_age = 17 AND user_level = 'A';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-j386Lpod-1688780333047)(.\img\04444.jpg)]

场景2: 直接跳过user_name使用索引字段，索引无效，未使用到索引。

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_age = 17 AND user_level = 'A';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-111H7Awo-1688780333047)(.\img\08.jpg)]
  
• 
  

场景3: 不按照创建联合索引的顺序,使用索引

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE 

user_age = 17 AND user_name = 'tom' AND user_level = 'A';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0IHrXbKh-1688780333048)(.\img\09.jpg)]

where后面查询条件顺序是 user_age、user_level、user_name与我们建的索引顺序user_name、user_age、user_level不一致，为什么还是使用了索引，这是因为MySql底层优化器给咱们做了优化。

• 但是，最好还是要按照顺序 使用索引。
  

最佳左前缀底层原理

MySQL创建联合索引的规则是: 首先会对联合索引最左边的字段进行排序 ( 例子中是 user_name ), 在第一个字段的基础之上 再对第二个字段进行排序 ( 例子中是 user_age )

所以: 最佳左前缀原则其实是个B+树的结构有关系, 最左字段肯定是有序的, 第二个字段则是无序的(联合索引的排序方式是: 先按照第一个字段进行排序,如果第一个字段相等再根据第二个字段排序). 所以如果直接使用第二个字段 user_age 通常是使用不到索引的.

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JtWzkEJk-1688780333048)(.\img\40.jpg)]

3. 不要在索引列上做任何计算

不要在索引列上做任何操作，比如计算、使用函数、自动或手动进行类型转换,会导致索引失效，从而使查询转向全表扫描。

• 插入数据

xxxxxxxxxx

INSERT INTO users(user_name,user_age,user_level,reg_time) VALUES('11223344',22,'D',NOW());

场景1: 使用系统函数 left()函数

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE LEFT(user_name, 6) = '112233';

• where条件使用计算后的索引字段 user_name，没有使用索引，索引失效。
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rKkyEog1-1688780333048)(.\img\10.jpg)]
  
• 
  

场景2: 字符串不加单引号 (隐式类型转换)

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 11223344;

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yUIxLJ38-1688780333049)(.\img\724444.jpg)]
  

注: Extra = Using where 表示Mysql将对storage engine提取的结果进行过滤，过滤条件字段无索引；

( 需要回表去查询所需的数据 )

4. 范围之后全失效

存储引擎不能使用索引中范围条件右边的列

• 场景1: 条件单独使用user_name时,type=ref, key_len=82

xxxxxxxxxx

-- 条件只有一个 user_name

EXPLAIN SELECT * FROM users WHERE user_name = 'tom';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lX7o3jjZ-1688780333049)(.\img\11.jpg)]

场景2: 条件增加一个 user_age ( 使用常量等值) ,type= ref , key_len = 86

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17;

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c4GzImnZ-1688780333049)(.\img\12.jpg)]
  
• 
  

场景3: 使用全值匹配, type = ref , key_len = 168 , 索引都利用上了.

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 'tom' 

AND user_age = 17 AND user_level = 'A';

场景4: 使用范围条件时, avg > 17 , type = range , key_len = 86 , 与场景3 比较,可以发现 user_level 索引没有用上.

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 'tom' 

AND user_age > 17 AND user_level = 'A';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mQRWgWE7-1688780333050)(.\img\14.jpg)]
  

5. 尽量使用覆盖索引

尽量使用覆盖索引（查询列和索引列尽量一致，通俗说就是对A、B列创建了索引，然后查询中也使用A、B列），减少select *的使用。

场景1: 全值匹配查询, 使用 select *

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name = 'tom' AND user_age = 17 

AND user_level = 'A';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aGRzWYP8-1688780333050)(.\img\15.jpg)]

场景1: 全值匹配查询, 使用 select 字段名1 ,字段名2

xxxxxxxxxx

EXPLAIN SELECT user_name , user_age , user_level FROM users WHERE user_name = 'tom' 

AND user_age = 17 AND user_level = 'A';

• 使用覆盖索引（查询列与条件列对应），可看到Extra从Null变成了Using index，提高检索效率。
  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dLEoWZXb-1688780333051)(.\img\16.jpg)]
  

注: Using index 表示 使用到了索引 , 并且所取的数据完全在索引中就能拿到,

(使用覆盖索引的时候就会出现)

6. 使用不等于（!=或<>）会使索引失效

使用 != 会使type=ALL，key=Null，导致全表扫描，并且索引失效。

使用 !=

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name != 'tom';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xfdbKRdk-1688780333051)(.\img\17.jpg)]
  

7. is null 或 is not null也无法使用索引

在使用is null的时候，索引完全失效，使用is not null的时候，type=ALL全表扫描，key=Null索引失效。

场景1: 使用 is null

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name IS NULL;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SFCRT8xA-1688780333052)(.\img\18.jpg)]

场景2: 使用 not null

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name IS NOT NULL;

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ectYGPOL-1688780333052)(.\img\19.jpg)]
  

8. like通配符以%开头会使索引失效

like查询为范围查询，%出现在左边，则索引失效。%出现在右边索引未失效。口诀：like百分加右边。

• 场景1

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name LIKE '%tom%';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7IcPJBim-1688780333052)(.\img\20.jpg)]
  
• 
  

场景2

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name LIKE '%tom';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5Dl4PQGs-1688780333053)(.\img\21.jpg)]
  
• 
  

场景3

xxxxxxxxxx

EXPLAIN SELECT * FROM users WHERE user_name LIKE 'tom%';

• [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-l8GJuXWz-1688780333053)(.\img\22.jpg)]
  

注: Using index condition 表示 查找使用了索引，但是需要;';查询数据

解决%出现在左边索引失效的方法：使用覆盖索引。

Case1:

xxxxxxxxxx
EXPLAIN SELECT user_name FROM users WHERE user_name LIKE '%jack%';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0gR1yhok-1688780333054)(.\img\23.jpg)]

• 对比场景1可以知道, 通过使用覆盖索引 type = index,并且使用了 Using index,从全表扫描变成了全索引扫描.

注: Useing where; Using index; 查找使用了索引，但是需要的数据都在索引列中能找到，所以不需要回表查询数据

Case2:

xxxxxxxxxx
EXPLAIN SELECT id FROM users WHERE user_name LIKE '%jack%';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wnQHiZ83-1688780333054)(.\img\24.jpg)]

• 这里出现 type=index，因为主键自动创建唯一索引。

Case3:

xxxxxxxxxx
EXPLAIN SELECT user_name,user_age FROM users WHERE user_name LIKE '%jack%';
EXPLAIN SELECT user_name,user_age,user_level FROM users WHERE user_name LIKE '%jack%';
EXPLAIN SELECT id,user_name,user_age,user_level FROM users WHERE user_name LIKE '%jack%';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mu0tyc6F-1688780333055)(.\img\21114.jpg)]

• 上面三组, explain执行的结果都相同，表明都使用了索引.

Case4:

xxxxxxxxxx
EXPLAIN SELECT id,user_name,user_age,user_level,reg_time FROM users WHERE user_name 
LIKE '%jack%';

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wye4Cwff-1688780333055)(.\img\25.jpg)]

• 分析：由于只在（user_name,user_age,user_level）上创建索引， 当包含reg_time时，导致结果集偏大（reg_time未建索引）【锅大，锅盖小，不能匹配】，所以type=ALL。
  

• like 失效的原理
  

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lp6qrEsY-1688780333056)(.\img\411110.jpg)]

1. %号在右: 由于B+树的索引顺序，是按照首字母的大小进行排序，%号在右的匹配又是匹配首字母。所以可以在B+树上进行有序的查找，查找首字母符合要求的数据。所以有些时候可以用到索引.
2. %号在左: 是匹配字符串尾部的数据，我们上面说了排序规则，尾部的字母是没有顺序的，所以不能按照索引顺序查询，就用不到索引.

1. 两个%%号: 这个是查询任意位置的字母满足条件即可，只有首字母是进行索引排序的，其他位置的字母都是相对无序的，所以查找任意位置的字母是用不上索引的.

9. 字符串不加单引号导致索引失效

varchar类型的字段，在查询的时候不加单引号导致索引失效，转向全表扫描。

场景1

xxxxxxxxxx

SELECT * FROM users WHERE user_name = '123';

SELECT * FROM users WHERE user_name = 123;

上述两条sql语句都能查询出相同的数据。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-72WuMtD3-1688780333056)(.\img\26.jpg)]

场景2:

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RJJJEOBa-1688780333056)(.\img\27.jpg)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DfJZmhRT-1688780333057)(.\img\28.jpg)]

通过explain执行结果可以看出，字符串（name）不加单引号在查询的时候，导致索引失效（type=ref变成了type=ALL，并且key=Null），并全表扫描。

10. 少用or，用or连接会使索引失效

在使用or连接的时候 type=ALL，key=Null，索引失效，并全表扫描。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-q0nH03HK-1688780333057)(.\img\29.jpg)]