字符串可以这样加索引，你知吗？《死磕MySQL系列 七》
Posted 咔咔-
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了字符串可以这样加索引，你知吗？《死磕MySQL系列 七》相关的知识，希望对你有一定的参考价值。
系列文章
六、五分钟，让你明白MySQL是怎么选择索引《死磕MySQL系列 六》
相信大多数小伙伴跟咔咔一样，给字符串添加索引从未设置过长度，今天就来聊聊如何正确的给字符串加索引。
一、如何建立索引
大多数系统都会存在用户表，并且系统初始设计使用了手机号码登录的。
这是产品提出了一个需求，让系统也可以支持邮箱登录。
肯定知道的是若不给邮箱字段添加索引执行查询是会全表扫描。
此时你心里窃喜这还不简单，给邮箱字段加个索引完事呗！但要做到复杂的需求做好，简单的需求要最好，减轻一切对系统的压力。
此时的你拿起键盘就执行了alter table table_name add index idx_field (field)
有部分小伙伴不喜欢命令行创建索引，喜欢使用phpmyadmin工具来操作mysql，那么在建立索引时有没有发现后边可以设置大小呢？
通过上边给大家展示的图片知道字符串建立索引是可以定义长度的，那么两者有什么区别。
使用命令行alter table table_name add index idx_field (field)直接创建的索引默认是包含整个字符串。
若这样执行就指定了索引前缀长度alter table table_name add index idx_field (field(6))
一图解千愁，看一下建立的两个索引结构是什么样的。
索引一结构图
索引二结构图
从图中可以看到，指定了索引长度为6那么就只取邮箱字段的前6个字段，相对索引包含整个字符串来说每个节点存储的数据会更多。
索引那篇文章也给大家说了建立索引在合适的范围内越小越好。
万物皆两面，有坏就有好，第六期文章误选索引的因素之一就是扫描行数。
索引长度减少带来的影响就是索引基数变大，从而增加额外的扫描记录数（执行explain的row字段）。
此时要执行select id,name,email from mac_user where email=\'1397393964@qq.com\';
给整个字符串添加索引执行流程
1、从email索引树找到满足1397393964@qq.com的记录，得到主键ID为1
2、根据ID为1到主键索引树找到这条记录并判断email是否正确，将这行记录假如结果集。
3、重复第一步，直到不满足查询条件，循环结束。
指定索引长度执行流程
1、从email索引树找到满足139739的记录，得到主键ID为1
2、根据ID为1到主键索引树找到这条记录并判断email不正确，丢弃这行记录。
3、在email索引树找刚刚查询的下一条记录，发现还是139739，去除ID2，再到ID的索引树进行判断，当值对后加入结果集。
4、再继续重复上一步，直到不满足查询条件，循环结束。
结论
在模拟执行流程过程中很容易就发现，使用前缀索引会导致读取数据的次数增加，那是不是就代表使用前缀索引会增加查询代价呢？
肯定不是的，试想此时定义的长度是6那么设置为7或者8呢！是不是会好很多，图中的案例为了方便设置了三个一样的数据，但实际情况基本不会出现这样的情况。
建立索引关注的是区分度，只有区分度越高，重复值就越少，查询效率就越高。
所以使用前缀索引，只要定义好长度，就可以坐到既节省空间，又不用额外增加太多的查询代价。
二、创建索引如何确定使用多长的前缀
MySQL中关键词distinct可以返回本列不同的结果集。
例如查询email列有多少个不同的值select count(distinct email) as num from mac_user。
如何计算列不同前缀有多少行
结合MySQL自带的函数left来实现，例如select count(distinct left (email,4)) as num4 from mac_user，截取email的前四个字符串计算有多少行。
再用这个值去除总数得到的就是比例，根据业务情况来判断多少比例可以。
三、使用前缀索引的影响
使用前缀索引会增加扫描行数，同时也会使覆盖索引失效。
为什么会影响覆盖索引？
若执行语句为select id,email from mac_user where email = \'1397393964@qq.com\'。
使用整个字符串索引结构查询可以使用覆盖索引，从email索引获取到结果就直接返回了，不用再进行回表。
若使用前缀索引在email索引获取到结果后还需要回到id索引在查一下判断查询的email的值是否正确。
哪怕是设置了大于了email的长度也会回表再进行判断，因为MySQL并不知道定义的前缀是否截取了完整信息。
结论
使用前缀索引会增加扫描行数，同样也使用不到覆盖索引。这个因素是你选择是否使用前缀索引要考虑的一个因素。
如果你不知道使用前缀索引还是全字符串索引，本地进行测试选一个合适的方案上到生产环境即可。
四、如何把不可以变为可以使用
假设身份认证系统存储的是身份证号，应该都知道身份证号前6位是地址码，同县的身份证号前6位一般是一样的。
这样使用前缀索引的话区分度会十分低，不但没有起到加速查询的作用，反而会造成索引区分度不大影响查询性能。
若把索引长度越长则每个节点存放的索引值就越少，查询效率也会变的低效。
如果解决这种场景
第一种方案
存储数据时将数据倒叙存储，查询时在正序处理一下即可
第二种方案
在表中新增一个字段，存储数据的hash值，给hash添加前缀索引。
区别
使用这两种方案共同点都不支持范围查询，都只能等值查询。
从占用空间来看：倒叙方式不会增加额外的存储空间，hash会增加一个字段。两者在空间不相上下
从CPU消耗来看：倒叙需要使用函数reverse，hash需要使用crc32 ，reverse消耗会小
从查询效率来看：hash查询更稳定，crc32计算的值虽有冲突但概率非常小，基本每次查询的平均扫描行数接近1。而倒叙使用的前缀索引方式，还会增加扫描行数。
五、总结
直接给字符串创建占用空间。
创建前缀索引，节省空间，会增加扫描行数，无法使用覆盖索引。
倒叙存储，创建前缀索引解决区分度不大的问题。
使用hash方式，查询稳定，不支持范围查询。
“坚持学习、坚持写作、坚持分享是咔咔从业以来所秉持的信念。愿文章在偌大的互联网上能给你带来一点帮助，我是咔咔，下期见。
”
为什么MySQL字符串不加引号索引失效？《死磕MySQL系列 十一》
群里一个小伙伴在问为什么MySQL字符串不加单引号会导致索引失效，这个问题估计很多人都知道答案。没错，是因为MySQL内部进行了隐式转换。
本期文章就聊聊什么是隐式转换，为什么会发生隐式转换。
系列文章
字符串可以这样加索引，你知吗？《死磕MySQL系列 七》
什么？还在用delete删除数据《死磕MySQL系列 九》
MySQL统计总数就用count(*)，别花里胡哨的《死磕MySQL系列 十》
一、几大索引失效原因
你肯定在网上看到过非常多关于索引失效原因的文章，但是一定要自己亲手尝试一下，因为版本不同引发的结果不会一致。
1.带头大哥不能死
这局经典语句是说创建索引要符合最左侧原则。
例如表结构为u_id，u_name，u_age，u_sex，u_phone，u_time
创建索引为idx_user_name_age_sex。
查询条件必须带上u_name这一列。
2.不在索引列上做任何操作
不在索引列上做任何计算、函数、自动或者手动的类型转换，否则会进行全表扫描。简而言之不要在索引列上做任何操作。
3.俩边类型不等
例如建立了索引idx_user_name，name字段类型为varchar
在查询时使用where name = kaka，这样的查询方式会直接造成索引失效。
正确的用法为where name = "kaka"。
4.不适当的like查询会导致索引失效
创建索引为idx_user_name
执行语句为select * from user where name like "kaka%";可以命中索引。
执行语句为select name from user where name like "%kaka";可以使用到索引（仅在8.0以上版本）。
执行语句为select * from user where name like \'\'%kaka";会直接导致索引失效
5.范围条件之后的索引会失效
创建索引为idx_user_name_age_sex
执行语句select * from user where name = \'kaka\' and age > 11 and sex = 1;
上面这条sql语句只会命中name和age索引，sex索引会失效。
复合索引失效需要查看key_len的长度即可。
总结：%在后边会命令索引，当使用了覆盖索引时任何查询方式都可命中索引。
以上就是咔咔关于索引失效会出现的原因总结，在很多文章中没有标注MySQL版本，所以你有可能会看到is null 、or索引会失效的结论。
二、从规则方面说明索引失效的原因
问题的答案就是第3点，两边类型不一致导致索引失效。
下图是表结构，目前这个表存在两个索引，一个主键索引，一个普通索引phone。
分别执行以下两条SQL语句
explain select * from evt_sms where phone = 13020733815;
explain select * from evt_sms where phone = \'13020733815\';
从上图可看出，执行第一条SQL没有使用到索引，第二条SQL却使用到了索引。
不错，你也发现了两条SQL的不同，第二条SQL跟第一条SQL逻辑一致，不同的是一个查询条件有引号，一个没有。
问题：为什么逻辑相同的SQL却是用不了索引
选择索引是优化器大哥的工作，大哥做事肯定轮不到咱们去教，因为大哥有自己的一套规则。
对于优化器来说，如果等号两边的数据类型不一致，则会发生隐式转换。
例如，explain select * from evt_sms where phone = 13020733815;这条SQL语句就会变为explain select * from evt_sms where cast(phone as signed int) = 13020733815;
由于对索引列进行了函数操作，从而导致索引失效。
问题：为什么会把左侧的列转为int类型呢？
优化器大哥就是根据这个规则进行判断，是把字符串转为数字，还是把数字转为字符串。
若返回1，则把字符串转为数字。
若返回0，则把数字转为字符串。
问题：select * from evt_sms where id = "193014410456945216"这条SQL语句能用上索引吗？
如果你忘记了表结构，可以翻到文章开头再看下表evt_sms的索引。
可以知道列id添加了主键索引，类型为int类型。
根据规则得到，MySQL8.0以上的版本是将字符串转为数字。
所以说，函数操作的是等号右边的数据，跟索引列没有关系，所以可以用上索引。
那么来到数据库验证一下结论，你答对了吗？
三、从索引结构说明索引失效原因
有这样一个需求，要统计每年双11注册用户数量。
可以看到在evt_sms表中是没有给create_time创建索引的，于是你会执行alter table evt_sms add index idx_ctime(create_time)，给create_time添加上索引。
接着你就执行了下面的SQL语句。
explain select count(*) from evt_sms where month(create_time) = 11;
上线没一会数据库出现了大量的慢查询，导致非常多的SQL返回失败。
此时公司大牛肯定会直接指出问题，索引列进行函数操作。
问题：为什么索引列使用函数就用不上索引了呢？
你现在看到的create_time索引结构图。
若此时执行的是where create_time = \'2021-11-16\'，那么MySQL就会非常快的等位到对应位置，并返回结果。
但是，做了函数操作，例如month(2021-11-16)得到的值是11。
当MySQL拿到返回的这个11时，在索引结构中根据就不知道怎么办。MySQL之所以能使用快速定位，是因为B+树的有序性。
而使用了函数对索引列进行操作后就会破坏索引的有序性，因此优化器大哥会选择执行代价最低的索引来继续执行。
四、结论
本期文章给大家介绍了两个案例，一个隐式转换，一个对索引列进行函数操作。
两种情况的本质是一样的，都是在索引列上进行了函数操作，导致全表扫描。
类似于这两种情况的还是字符集问题，不过一般这个问题会会很少发生，如有新业务需要新创建表，都会设置为之前的字符集。
两张表的字符集不同在进行join时也会导致隐式字符集转换，导致索引失效。
“坚持学习、坚持写作、坚持分享是咔咔从业以来所秉持的信念。愿文章在偌大的互联网上能给你带来一点帮助，我是咔咔，下期见。
”
以上是关于字符串可以这样加索引，你知吗？《死磕MySQL系列 七》的主要内容，如果未能解决你的问题，请参考以下文章