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关联字段字符集排序规则造成索引失效的主要内容,如果未能解决你的问题,请参考以下文章