浅谈MySql整型索引和字符串索引失效或隐式转换问题

问题概述

今天在上班时，dba突然找出来一段sql，表示该sql存在隐式转换，不走索引。经过我们的查看后，发现是类型varchar的字段， 我们使用条件传入了数值型的值，由于担心违反保密协议，在此就不贴图了，由我重现一下类似情况给大家看一下。

问题重现

首先我们先创建一张用户表test_user，其中user_id为了效果我们设置为varchar类型且加上唯一索引。

create table test_user (
  id int(11) not null auto_increment,
  user_id varchar(11) default null comment '用户账号',
  user_name varchar(255) default null comment '用户名',
  age int(5) default null comment '年龄',
  comment varchar(255) default null comment '简介',
  primary key (id)
  unique key unique_user_id (user_id) using btree
) engine=innodb default charset=utf8;

表格数据如下（嘻嘻 数据依旧使用与上次mysql的文章mysql使用union连接两个查询排序失效相同的数据，但是要注意表结构不同。）

id	user_id	user_name	age	comment
1	111	开心菜鸟	18	今天很开心
2	222	悲伤菜鸟	21	今天很悲伤
3	333	认真菜鸟	30	今天很认真
4	444	高兴菜鸟	18	今天很高兴
5	555	严肃菜鸟	21	今天很严肃

接下来我们执行以下sql

explain select * from test_user where user_id = 111;

发现给出的解释结果如下：

id	select_type	table	partitions	type	possible_keys	key	key_len	ref	rows	filtered	extra
1	simple	test_user		all					5		using where

我们给条件加上引号后再解释以下：

explain select * from test_user where user_id = '111';

这时候我们发现varchar类型的字段在作为字符串查询的时候使用了索引，在以数值类型进行查询时是不使用索引的。

问题引申

那么问题来了，如果字段是整型的且加上索引，以字符串查询时会不会也不走索引呢？实践出真知，让我们再接着往下测试一下。

-- 将user_id的类型修改为整型
create table test_user (
  id int(11) not null auto_increment,
  user_id int(11) default null comment '用户账号',
  user_name varchar(255) default null comment '用户名',
  age int(5) default null comment '年龄',
  comment varchar(255) default null comment '简介',
  primary key (id),
  unique key unique_user_id (user_id) using btree
) engine=innodb auto_increment=6 default charset=utf8;

explain select * from test_user where user_id = 111;

explain select * from test_user where user_id = '111';

在执行了上面两个语句后我们发现，int类型的字段无论是以字符串查询还是以数值型查询都会走索引。

结论

1. 当我们使用的字段是数值类型时，加引号或者不加引号（sql中单引号和双引号实现相同效果）都不影响索引的使用
2. 当我们的字段是字符串类型时，不加引号的查询无法使用索引，加引号的查询才可正常使用索引

综上所述，我认为以后写sql的时候注意最好都加上引号，避免这种字符串类型的不走索引的情况发生，更深层次的原理需要再挖掘一下，如果大家有什么意见可以探讨一下。

到此这篇关于浅谈mysql整型索引和字符串索引失效或隐式转换问题的文章就介绍到这了,更多相关mysql整型索引和字符串索引失效内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！