需求

在日常需求中，用户使用手机号或者邮箱登录某一个系统，是一个很常见的操作，那如何在类似手机号或者邮箱这样的字段上建立一个合理的索引呢？

前缀索引

前缀索引，就是以一个字段值的一部分作为索引。我们在 MySQL 中创建索引时，如果不指定索引字段的长度，那么就会以整个字符串来建立索引。

语句1：alter table test add index idx(email);语句2：alter table test add index idx(email(8));

对于语句 1，创建的索引中，会包含每条记录中的整个 email 字符串值。

对于语句 2，创建的索引中，保存的是每条记录中 email 字段的前 8 个字节。

使用前缀索引的优势很明显，那就是索引占用的空间会更小，整个索引树会更紧凑，树的高度相对更低。

但是相应的，索引的区分度会变低，可能导致索引扫描行数增加。

在我们创建索引时，索引的区分度是一个很重要的指标。区分度越高，重复的值就越少，扫描的效率就越高。

在使用前缀索引时，合理规划使用的前缀长度，不仅可以节省空间，还可以不用额外增加扫描的行数。具体使用多少的长度，建议根据我们的实际业务场景来判断、测试。

倒序+前缀索引

倒序+前缀索引有一个经典的使用场景，就是对身份证号做索引。

假设我们现在要维护一个市县所有人的身份信息，其中按身份证号查询是一个高频场景。

身份证号码一共 15 位或者 18 位，一般来说，同一个市县的人身份证号前 6 位一般是相同的，如果直接对身份证号做全索引，那么会比较浪费空间，导致性能下降。直接前缀索引的话，前 6 位的区分度又很低（甚至可以说没有，因为大家前 6 位基本都一样）。

这时，使用倒序+前缀索引的好处就体现出来了。

我们先将身份证倒序存储，或者冗余一个倒序的身份证号字段，然后取前 6 位做前缀索引。

身份证后 6 位的区分度已经基本上够我们使用了，如果你还觉得查询速度不够，那取前 8 位也是没问题的。

总结

我们之所以尽量避免对字符串加全值索引，是因为字符串字段的长度不好预估，可能会变得很大。在一个值很大的字段上做索引，会额外的占用更多的空间，数据页上可存储的索引值会变少，导致 MySQL 树的高度变高，这样查询数据时，IO 增加，性能下降。

但是，凡事都有例外，有时我们也不能为了优化而优化。

比如我们现在要维护一个高校的师生信息，按整个学校 2 万人，每年新增 1 万新学生来计算，10 年时间也不过 12 万数据而已。即使在一个身份证号字段上加上全字段索引又能多占用多少空间呢？能省出多少性能呢？

有时，从业务量预估优化和收益比，也是一个很好的习惯。

写文不易，朋友们帮忙点点赞和关注吧。