MySQL字符串前缀索引详解

1. 前缀索引与全部索引概念
2. 前缀索引与全部索引数据结构
3. 前缀索引与全部索引引执行流程
4. 前缀索引长度如何取舍
5. 前缀索引对覆盖索引的影响
6. 其他解决方案
7. 梳理总结

1. 前缀索引与全部索引概念

怎么给字符串字段加索引？现在，几乎所有的系统都支持邮箱登录，如何在邮箱这样的字段上建立合理的索引，是我们今天要讨论的问题。

假设，你现在维护一个支持邮箱登录的系统，用户表是这么定义的

create table SUser(
ID bigint unsigned primary key,
email varchar(64),
name varchar(64),
...
)engine=innodb;

由于要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：

select f1, f2 from SUser where email='xxx';

我们知道，如果email这个字段上没有索引，那么这个语句就只能做全表扫描。

MySQL支持全部索引与前缀索引。MySQL是支持前缀索引的，也就是说，你可以定义字符串的一部分作为索引。默认地，如果你创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。

比如，这两个在email字段上创建索引的语句：

-- 全部索引，索引字段为email整个字符串
alter table SUser add index index1(email);-- 前缀索引，6表示索引字段为email的前6位
alter table SUser add index index2(email(6));

第一个语句创建的index1索引里面，包含了每个记录的整个字符串；而第二个语句创建的index2索引里面，对于每个记录都是只取前6个字节。

2. 前缀索引与全部索引数据结构

这两种不同的定义在数据结构和存储上有什么区别呢？如图2和3所示，就是这两个索引的示意图。
mysql全部索引数据结构
mysql前缀索引数据结构

从图中你可以看到，由于email(6)这个索引结构中每个邮箱字段都只取前6个字节（即：zhangs），所以占用的空间会更小，这就是使用前缀索引的优势。但，这同时带来的损失是，可能会增加额外的记录扫描次数。

3. 前缀索引与全部索引引执行流程

接下来，我们再看看下面这个语句，在这两个索引定义下分别是怎么执行的。
如 index1（即email整个字符串的索引结构），执行顺序是这样的：

从index1索引树找到满足索引值是’zhangssxyz@xxx.com’的这条记录，取得ID2的值；
到主键上查到主键值是ID2的行，判断email的值是正确的，将这行记录加入结果集；
取index1索引树上刚刚查到的位置的下一条记录，发现已经不满足email='zhangssxyz@xxx.com’的条件了，循环结束。
这个过程中，只需要回主键索引取一次数据，所以系统认为只扫描了一行。

如 index2（即email(6)索引结构），执行顺序是这样的：

从index2索引树找到满足索引值是’zhangs’的记录，找到的第一个是ID1；
到主键上查到主键值是ID1的行，判断出email的值不是’zhangssxyz@xxx.com’，这行记录丢弃；
取index2上刚刚查到的位置的下一条记录，发现仍然是’zhangs’，取出ID2，再到ID索引上取整行然后判断，这次值对了，将这行记录加入结果集；
重复上一步，直到在idxe2上取到的值不是’zhangs’时，循环结束。
在这个过程中，要回主键索引取4次数据，也就是扫描了4行。

通过这个对比，你很容易就可以发现，使用前缀索引后，可能会导致查询语句读数据的次数变多。

4. 前缀索引长度如何取舍

对于这个查询语句来说，如果你定义的index2不是email(6)而是email(7），也就是说取email字段的前7个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到ID2，只扫描一行就结束了。
也就是说使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查使询成本。
于是，你就有个问题：当要给字符串创建前缀索引时，有什么方法能够确定我应该使用多长的前缀呢？实际上，我们在建立索引时关注的是区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。因此，我们可以通过统计索引上有多少个不同的值来判断要使用多长的前缀。

首先，你可以使用下面这个语句，算出这个列上有多少个不同的值：

select count(distinct email) as L from SUser;

然后，依次选取不同长度的前缀来看这个值，比如我们要看一下4~7个字节的前缀索引，可以用这个语句：

select
count(distinct left(email,4)）as L4,
count(distinct left(email,5)）as L5,
count(distinct left(email,6)）as L6,
count(distinct left(email,7)）as L7,
from SUser;

当然，使用前缀索引很可能会损失区分度，所以你需要预先设定一个可以接受的损失比例，比如5%。然后，在返回的L4~L7中，找出不小于 L * 95%的值，假设这里L6、L7都满足，你就可以选择前缀长度为6。

5. 前缀索引对覆盖索引的影响

前面我们说了使用前缀索引可能会增加扫描行数，这会影响到性能。其实，前缀索引的影响不止如此，我们再看一下另外一个场景。

你先来看看这个SQL语句

select id,email from SUser where email='zhangssxyz@xxx.com';

与前面例子中的SQL语句

select id,name,email from SUser where email='zhangssxyz@xxx.com';

id是主键，email是索引，name不是索引的情况下，先说结论，当email是全部索引的时候第一个sql会走覆盖索引，第二个不会走覆盖索引，当email为前缀索引的时候哪怕前缀为全部字符串长度依然无法走覆盖索引。

所以，如果使用index1（即email整个字符串的索引结构）的话，可以利用覆盖索引，从index1查到结果后直接就返回了，不需要回到ID索引再去查一次。而如果使用index2（即email(6)索引结构）的话，就不得不回到ID索引再去判断email字段的值。

即使你将index2的定义修改为email(18)的前缀索引，这时候虽然index2已经包含了所有的信息，但InnoDB还是要回到id索引再查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。

也就是说，使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素。

6. 其他解决方案

对于类似于邮箱这样的字段来说，使用前缀索引的效果可能还不错。但是，遇到前缀的区分度不够好的情况时，我们要怎么办呢？

比如，我们国家的身份证号，一共18位，其中前6位是地址码，所以同一个县的人的身份证号前6位一般会是相同的。假设你维护的数据库是一个市的公民信息系统，这时候如果对身份证号做长度为6的前缀索引的话，这个索引的区分度就非常低了。按照我们前面说的方法，可能你需要创建长度为12以上的前缀索引，才能够满足区分度要求。但是，索引选取的越长，占用的磁盘空间就越大，相同的数据页能放下的索引值就越少，搜索的效率也就会越低。

那么，如果我们能够确定业务需求里面只有按照身份证进行等值查询的需求，还有没有别的处理方法呢？这种方法，既可以占用更小的空间，也能达到相同的查询效率。答案是，有的。

第一种方式是使用倒序存储。第如果你存储身份证号的时候把它倒过来存，每次查询的时候，你可以这么写：

select field_list from t where id_card = reverse('input_id_card_string');

由于身份证号的最后6位没有地址码这样的重复逻辑，所以最后这6位很可能就提供了足够的区分度。当然了，实践中你不要忘记使用count(distinct)方法去做个验证。

第二种方式是使用第 hash h 字段。字你可以在表上再创建一个整数字段，来保存身份证的校验码，同时在这个字段上创建索引。

 alter table t add id_card_crc int unsigned, add index(id_card_crc);

然后每次插入新记录的时候，都同时用crc32()这个函数得到校验码填到这个新字段。由于校验码可能存在冲突，也就是说两个不同的身份证号通过crc32()函数得到的结果可能是相同的，所以你的查询语句where部分要判断id_card的值是否精确相同。

select field_list from t where id_card_crc=crc32('input_id_card_string') and id_card='input_id_card_string'

这样，索引的长度变成了4个字节，比原来小了很多。

接下来，我们再一起看看使用倒序存储和使用使 hash h 字段这两种方法的异同点。字首先，它们的相同点是，都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在[ID_X, ID_Y]的所有市民了。同样地，hash字段的方式也只能支持等值查询。

它们的区别，主要体现在以下三个方面：

从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而hash字段方法需要增加一个字段。当然，倒序存储方式使用4个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个hash字段也差不多抵消了。
在CPU消耗方面，倒序方式每次写和读的时候，都需要额外调用一次reverse函数，而hash字段的方式需要额外调用一次crc32()函数。如果只从这两个函数的计算复杂度来看的话，reverse函数额外消耗的CPU资源会更小些。
从查询效率上看，使用hash字段方式的查询性能相对更稳定一些。因为crc32算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。

7. 梳理总结

总体来说的话全部索引会占用一部分空间，但是可以走覆盖索引，区分度比较高，减少回表次数，前缀索引虽然减少了部分空间，但是需要平衡区分度，而且需要时刻关注表中索引字段的变化，因为随着数据的变化区分度也会变化，可能原来前缀6个字段区分度就能达到95%以上，但是随着数据增加前6个字段只能达到60%的区分度，另外一点就是覆盖索引无法使用，虽然倒叙或者hash能解决空间问题，但是又会产生新的问题，比如需要函数，增加字段等，是查询效率降低，折中选择全部索引会更加稳妥，效率更高，当然对于特定的字符串比如自己公司email，前6位足够区分，而且后续不会有改动，这时前缀索引既能减少空间占用，又能达到与全部索引一样的效果，使用前缀会更好。具体使用场景一定是结合具体的业务场景选择。

MySQL字符串前缀索引详解相关推荐

高性能Mysql——创建高性能索引详解
索引(在MySQL中也叫做"键(key)")是存储引擎用于快速找到记录的一种数据结构.这是索引的基本功能,除此之外,本章还将讨论索引其他一些方面有用的属性. 索引对于良好的性能非常 ...
Mysql探索之索引详解，又能和面试官互扯了~，java分布式系统面试题
不在哪些列建索引? 对于那些在查询中很少使用或者参考的列不应该创建索引.这是因为,既然这些列很少使用到,因此有索引或者无索引,并不能提高查询速度.相反,由于增加了索引,反而降低了系统的维护速度和增大了 ...
最全面的 MySQL 索引详解
本文章来自 http://www.codeceo.com/article/mysql-index-2.html 什么是索引? 1.索引索引是表的目录,在查找内容之前可以先在目录中查找索引位置,以此快 ...
mysql索引 include_MySql索引详解
什么是索引? 1.索引索引是表的目录,在查找内容之前可以先在目录中查找索引位置,以此快速定位查询数据.对于索引,会保存在额外的文件中. 2.索引,是数据库中专门用于帮助用户快速查询数据的一种数据结构 ...
【MySQL】MySQL的存储引擎和索引详解（聚集索引和非聚集索引）
目录一.MySQL存储引擎 1.1 Innodb引擎 1.2 MyISAM引擎 1.3 InNoDB与MyISAM异同 1.4 两种引擎的选择二.索引(Index) 2.1 InnoDB存储引擎 ...
mysql 联合索引详解
mysql 联合索引详解联合索引又叫复合索引.对于复合索引:Mysql从左到右的使用索引中的字段,一个查询可以只使用索引中的一部份,但只能是最左侧部分.例如索引是key index (a,b,c). ...
MySQL操作mysqldump命令详解
MySQL操作mysqldump命令详解基本命令: # 数据库备份-->mysqldump命令默认做锁表操作 mysqldump -uroot -ppassword --all-databas ...
MySQL调试--explain命令详解
原文网址:MySQL调试--explain命令详解_IT利刃出鞘的博客-CSDN博客简介本文介绍MySQL的explain命令的用法及其结果的含义. explain作用概述在 SELECT 语 ...
MySQL mysqldump数据导出详解
MySQL mysqldump数据导出详解 2016-04-07 11:14 pursuer.chen 阅读(357122) 评论(2) 编辑收藏举报介绍在日常维护工作当中经常会需 ...

MySQL字符串前缀索引详解

MySQL字符串前缀索引详解

1. 前缀索引与全部索引概念

2. 前缀索引与全部索引数据结构

3. 前缀索引与全部索引引执行流程

4. 前缀索引长度如何取舍

5. 前缀索引对覆盖索引的影响

6. 其他解决方案

7. 梳理总结

MySQL字符串前缀索引详解相关推荐

最新文章

热门文章