MySQL实战45讲_11 | 怎么给字符串字段加索引?

310 阅读7分钟

11 | 怎么给字符串字段加索引?

现在几乎所有的系统都支持邮箱登录,如何在邮箱这样的字段上建立合理的索引呢?

假设一个支持邮箱登录的系统,用户表是这样定义的:

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

由于要使用邮箱登录,业务代码中就会出现类似语句:mysql> select f1, f2 from SUser where email='xxx';

从之前介绍索引的文章来看,如果email字段上没有索引,那么这个语句就只能做全表扫描。Mysql支持前缀索引,即可以定义字符串的一部分作为索引。例如:

mysql> alter table SUser add index index1(email); 
或 
mysql> alter table SUser add index index2(email(6));

那么,这两种不同的定义在数据结构和存储上有什么区别呢?如图所示,就是这两个索引的示意图。

image.png

image.png

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

接下来,我们再看看下面这个语句,在这两个索引定义下分别是怎么执行的。

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

如果使用的是index1(即email整个字符串的索引结构),执行顺序是这样的:

  1. 从index1索引树找到满足索引值是’zhangssxyz@xxx.com’的这条记录,取得ID2的值;
  2. 到主键上查到主键值是ID2的行,判断email的值是正确的,将这行记录加入结果集;
  3. 取index1索引树上刚刚查到的位置的下一条记录,发现已经不满足 email='zhangssxyz@xxx.com’的条件了,循环结束。

这个过程中,只需要回主键索引取一次数据,所以系统认为只扫描了一行。

如果使用的是index2(即email(6)索引结构),执行顺序是这样的:

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

在这个过程中,要回主键索引取4次数据,也就是扫描了4行。

使用前缀索引后,可能会导致查询语句读数据的次数变多。 但是,如果你定义的index2不是email(6)而是email(7),也就是说取email字段的前7个字节来构建索引的话,即满足前缀’zhangss’的记录只有一个,也能够直接查到ID2,只扫描一行就结束了。

使用前缀索引,定义好长度,就可以做到既节省空间,又不用额外增加太多的查询成本。

当要给字符串创建前缀索引时,怎么确定应该使用多长的前缀呢?

区分度越高越好。因为区分度越高,意味着重复的键值越少。因此,我们可以通过统计索引上有多少个不同的值来判断要使用多长的前缀。

mysql> select count(distinct email) as L from SUser;

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

mysql> 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

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

关于覆盖索引:

  1. 解释一: 就是select的数据列只用从索引中就能够取得,不必从数据表中读取,换句话说查询列要被所使用的索引覆盖。
  2. 解释二: 索引是高效找到行的一个方法,当能通过检索索引就可以读取想要的数据,那就不需要再到数据表中读取行了。如果一个索引包含了(或覆盖了)满足查询语句中字段与条件的数据就叫做覆盖索引。
  3. 解释三:是非聚集组合索引的一种形式,它包括在查询里的Select、Join和Where子句用到的所有列(即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段,也即,索引包含了查询正在查找的所有数据)。 先来看这两个语句:
select id,email from SUser where email='zhangssxyz@xxx.com';
select id,name,email from SUser where email='zhangssxyz@xxx.com';

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

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

其他方式

例如身份证号,共18位,前六位是地址码,前缀索引需要到12位以上才能满足区分度要求,但是这样占用磁盘空间就越大,相同数据页放下的索引值越少,搜索效率越低。那么如何满足区分度高的同时搜索效率也高呢?

第一种方式:倒序存储。由于身份证号的最后6位没有地址码这样的重复逻辑,所以最后这6位很可能就提供了足够的区分度。

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

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

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

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

倒序存储和hash字段的区别:

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