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

小艾

Mysql

发布于：Jun 20, 2022

1.7k words

6 min

本文是基于极客时间——MySQL 实战 45 讲整理的学习笔记，仅供学习参考，请勿用于商业用途，如若侵权，请联系并删除。

课程重点：

前缀索引与全字段索引

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

对于前缀索引和全字段索引来说，这两种不同的定义在数据结构和存储上有什么区别呢？

全字段索引：

前缀索引：

从上图中可以看到，前缀索引结构中每个邮箱字段都只取前 6 个字节（即：zhangs），所以占用的空间会更小，这就是使用前缀索引的优势。

但，这同时带来的损失是，可能会增加额外的记录扫描次数。

接下来从微观的角度来看一下，在这两个不同的索引下，执行过程分别是怎样的。

如果使用的是 index1（即 email 整个字符串的索引结构），执行顺序是这样的：

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

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

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

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

先来看看这个 SQL 语句：

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

与前面例子中的 SQL 语句

1	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 索引再查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。

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

第一种方式是使用倒序存储。

有时候有些业务场景的前缀是一样的，这个时候如果继续使用前缀索引，其实没有太大意义。

这个时候可以考虑使用倒序存储。

第二种方式是使用 hash 字段。

可以在表上再创建一个整数字段，来保存字段的校验码，同时在这个字段上创建索引。

然后每次插入新记录的时候，都同时用 crc32() 这个函数得到校验码填到这个新字段。

由于校验码可能存在冲突，也就是说两个不同的值通过 crc32() 函数得到的结果可能是相同的，所以你的查询语句 where 部分要判断字段的值是否精确相同。

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

使用倒序存储和使用 hash 字段这两种方法的异同点。

相同点：都不支持范围查询。倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在 [ID_X, ID_Y] 的所有市民了。同样地，hash 字段的方式也只能支持等值查询。
异同点：
- 从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。当然，倒序存储方式使用 4 个字节的前缀长度应该是不够的，如果再长一点，这个消耗跟额外这个 hash 字段也差不多抵消了。
- 在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。如果只从这两个函数的计算复杂度来看的话，reverse 函数额外消耗的 CPU 资源会更小些。
- 从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。