MySQL实战45讲 11
11 | 怎么给字符串字段加索引？Q：如何在邮箱这样的字段上建立合理的索引？
用户表的定义：
create table SUser(
ID bigint unsigned primary key,
email varchar(64),
...
)engine=innodb; 由于要使用邮箱登录，所以业务代码中一定会出现类似于这样的语句：
select f1, f2 from SUser where email='xxx';如果 email 这个字段上没有索引，那么这个语句就只能做全表扫描。
A：
前缀索引
MySQL 是支持前缀索引的，也就是说，可以定义字符串的一部分作为索引。
默认地，如果你创建索引的语句不指定前缀长度，那么索引就会包含整个字符串。
alter table SUser add index index1(email);
alter table SUser add index index2(email(6));第一个语句创建的 index1 索引里面，包含了每个记录的整个字符串；
而第二个语句创建的 index2 索引里面，对于每个记录都是只取前 6 个字节。
在数据结构和存储上的区别：
https://img2022.cnblogs.com/blog/2152366/202207/2152366-20220723185946216-1816973172.webp
https://img2022.cnblogs.com/blog/2152366/202207/2152366-20220723185945333-438613567.webp
由于 email(6) 这个索引结构中每个邮箱字段都只取前 6 个字节（即：zhangs），所以占用的空间会更小，这就是使用前缀索引的优势。
这同时带来的损失是，可能会增加额外的记录扫描次数。
执行上面的select时：
如果使用的是 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’时，循环结束。
所以使用前缀索引后，可能会导致查询语句读数据的次数变多。
使用多长的前缀呢？
在建立索引时关注的是区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。
以通过统计索引上有多少个不同的值来判断要使用多长的前缀。
首先算出这个列上有多少个不同的值：
select count(distinct email) as L from SUser;然后，依次选取不同长度的前缀来看这个值：
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;前缀索引对覆盖索引的影响
select id,email from SUser where email='zhangssxyz@xxx.com';使用index1，由于通过email可以直接找到id，即覆盖索引，不需要回表。
使用index2（即 email(6) 索引结构）的话，就不得不回到 ID 索引再去判断 email 字段的值。
即使你将 index2 的定义修改为 email(18) 的前缀索引，这时候虽然 index2 已经包含了所有的信息，但 InnoDB 还是要回到 id 索引再查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。
前缀索引就用不上覆盖索引对查询性能的优化
其他方式
Q：遇到前缀的区分度不够好的情况时，要怎么办？例如身份证号码？
希望能既可以占用更小的空间，也能达到相同的查询效率
A：
第一种方式是使用倒序存储。如果你存储身份证号的时候把它倒过来存，每次查询的时候，你可以这么写
select field_list from t where id_card = reverse('input_id_card_string');由于身份证号的最后 6 位没有地址码这样的重复逻辑，所以最后这 6 位很可能就提供了足够的区分度
第二种方式是使用 hash 字段。你可以在表上再创建一个整数字段，来保存身份证的校验码，同时在这个字段上创建索引。
alter table t add id_card_crc int unsigned, add index(id_card_crc);然后每次插入新记录的时候，都同时用 crc32() 这个函数得到校验码填到这个新字段。
crc32 - 计网数据库中常使用 返回字符串的 32 位循环冗余校验值。
由于校验码可能存在冲突，也就是说两个不同的身份证号通过 crc32() 函数得到的结果可能是相同的，所以你的查询语句 where 部分要判断 id_card 的值是否精确相同。
使用倒序存储和使用 hash 字段这两种方法的异同点
相同点是，都不支持范围查询。
倒序存储的字段上创建的索引是按照倒序字符串的方式排序的，已经没有办法利用索引方式查出身份证号码在 的所有市民。同样地，hash 字段的方式也只能支持等值查询。
区别，主要体现在以下三个方面：
[*]从占用的额外空间来看，倒序存储方式在主键索引上，不会消耗额外的存储空间，而 hash 字段方法需要增加一个字段。
[*]在 CPU 消耗方面，倒序方式每次写和读的时候，都需要额外调用一次 reverse 函数，而 hash 字段的方式需要额外调用一次 crc32() 函数。
[*]从查询效率上看，使用 hash 字段方式的查询性能相对更稳定一些。因为 crc32 算出来的值虽然有冲突的概率，但是概率非常小，可以认为每次查询的平均扫描行数接近 1。而倒序存储方式毕竟还是用的前缀索引的方式，也就是说还是会增加扫描行数。
总结
[*]直接创建完整索引，这样可能比较占用空间；
[*]创建前缀索引，节省空间，但会增加查询扫描次数，并且不能使用覆盖索引；
[*]倒序存储，再创建前缀索引，用于绕过字符串本身前缀的区分度不够的问题；
[*]创建 hash 字段索引，查询性能稳定，有额外的存储和计算消耗，跟第三种方式一样，都不支持范围扫描。
Q：如果你在维护一个学校的学生信息数据库，学生登录名的统一格式是"学号 @gmail.com"
学号的规则是：十五位的数字，其中前三位是所在城市编号、第四到第六位是学校编号、第七位到第十位是入学年份、最后五位是顺序编号。
系统登录的时候都需要学生输入登录名和密码，验证正确后才能继续使用系统。就只考虑登录验证这个行为的话，会怎么设计这个登录名的索引呢？
A:
因为维护的只是一个学校的，因此前面 6 位（其中，前三位是所在城市编号、第四到第六位是学校编号）其实是固定的，邮箱后缀都是 @gamil.com，因此可以只存入学年份加顺序编号，它们的长度是 9 位。
而其实在此基础上，可以用数字类型来存这 9 位数字。比如 201100001，这样只需要占 4 个字节。其实这个就是一种 hash，只是它用了最简单的转换规则：字符串转数字的规则，而刚好我们设定的这个背景，可以保证这个转换后结果的唯一性。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]