mysql索引失效的情况以及left join关联字段字符集排序规则造成索引失效

Posted 健康平安的活着

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql索引失效的情况以及left join关联字段字符集排序规则造成索引失效相关的知识,希望对你有一定的参考价值。

一 索引失效的情况

1.1 新建表

CREATE TABLE `tb_user` (
  `id` int(10) NOT NULL AUTO_INCREMENT,
  `u_name` varchar(255) DEFAULT NULL,
  `address` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `n_index` (`u_name`) USING BTREE COMMENT '加快检索',
  KEY `add_index` (`address`) USING BTREE COMMENT '加快检索'
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

1.1.1 like模糊匹配的时候以%开头

1.错误:

desc
select u_name,address from tb_user where u_name like '%ljf'

 2.正确:


desc
select u_name from tb_user where u_name like 'ljf%'

 1.1.2  据类型隐式或显式转换

1.错误

desc 
select u_name , address from tb_user where u_name=34

 2.正确

 1.1.3 多表联合查询的关联字段的排序规则或字符集不相同

见后面案例详解

通过以下方法查看表的字符集和排序规则:

 1.1.4  多表联合查询的关联字段的排序规则或字符集不相同

1.错误

desc
select u_name,address from tb_user where substr(u_name,1,2)='lj'

 2.正确

desc 
select u_name,address from tb_user where  u_name='lj'

 1.1.5  违反联合索引的最左匹配规则

1.错误

desc 
select u_name,address from tb_user where  create_time>='2022-07-08 00:00:00'

2.正确

desc 
select u_name,address from tb_user where  u_name='ljf' and create_time>='2022-07-08 00:00:00'

 

二  left join关联字段字符集和排序规则不同造成索引失效

2.1 问题描述

1.表a  的字段gl_data_point_code的字符集为:utf8mb4,排序规则为utf8mb4_bin

 1.表a的索引

2.表b的gl_data_point_code的字符集为 utf8 排序规则为utf8_general_ci

 2.表b的索引

两张表的关联字段gl_data_point_code都建立了索引。 

3.两张表的数据量为:4176 和34090

 4.写关联查询sql:

select  a.gl_data_point_code,b.gl_data_point_code from gl_pre_warn_fault_config as a  left join gl_data_point_mapping as b on a.gl_data_point_code=b.gl_data_point_code 

可以看到耗时:24.943秒

查看执行计划:可以看到a表使用到了normal索引 gl_index,b表使用了unique索引且extar中存在:Using join buffer (Block Nested Loop)  ,耗时24s多,简直不能容忍!!!

 2.2 解决办法

结果排查,好巧不巧,中招了,根据前面列举出两张表的关联字段gl_data_point_code的字符集不同一个:表a  的字段gl_data_point_code的字符集为:utf8mb4,排序规则为utf8mb4_bin;表b的gl_data_point_code的字符集为 utf8 排序规则为utf8_general_ci。正好违背了多表联合查询的关联字段的排序规则或字符集不相同,索引失效的情况。

1.这里将a表中gl_data_point_code字符集修改成:字符集为 utf8 排序规则为utf8_general_ci

2.再次执行sql:可以看到耗时0.054s  从24秒 提速到0.054秒

3.查看sql执行计划:b表使用了unique索引且extar中为:Using index

 2.3 原因分析

这是因为两个表的关联字段gl_data_point_code字符集不同,一个是utf8,一个是utf8mb4,所以做表连接查询的时候用不上关联字段的索引。utf8mb4是utf8的超集,所以当这两个类型的字符串在做比较的时候,mysql内部的操作是先将utf8转换成utf8mb4字符集,再做比较。

 select  a.gl_data_point_code,b.gl_data_point_code from gl_pre_warn_fault_config as a  left join gl_data_point_mapping as b on         convert(a.gl_data_point_code  using utf8 ) =b.gl_data_point_code 

这就会触发:对索引字段做函数操作,优化器会放弃树搜索功能, 关联字段的索引失效。

结论:

如果将两个表的关联字段的字符集不相同,而且排序规则也不同,那么索引会失效。

如果将两个表的关联字段的字符集保持相同,但是排序规则不同,那么索引会失效。

有没有排序规则相同而字符集不同呢?哈哈哈,显然是没有的,排序规则就是根据字符集来定义的。

以上是关于mysql索引失效的情况以及left join关联字段字符集排序规则造成索引失效的主要内容,如果未能解决你的问题,请参考以下文章

MySQL(十六)索引优化:索引失效的情况分析

mysql多表left join联合查询效率问题5

mysql left join 右表存在重复数据,怎么处理

Mysql(14)—高性能的索引策略以及常见索引失效的情况

Mysql(13)—高性能的索引策略以及常见索引失效的情况

Mysql索引优化分析-第一篇