MySQL索引原理

1. 概述

如果你有以下疑问，值得往下看：

1、业务ID能保证唯一性，是不是可以考虑不使用自增主键？自增主键和业务ID做主键，底层到底有什么区别？

2、同样是索引，条件中使用主键索引作为条件和非主键索引作为条件，性能一样吗？

3、为什么有人说，对于邮箱地址这种数据比较长的字段，不适合直接创建索引？

4、创建独立字段的索引，查询已经很快，为什么我们还需要考虑创建组合索引？什么场景下需要创建组合索引？

5、覆盖索引和回表是啥意思？

2. 常见问题

阅读正文前，建议大家做个小调研，带着这些问题往下看，参考答案在后面。

1. 唯一索引和普通索引性能有差异吗？单选

• 唯一索引性能更好

• 普通索引更好

• 其它

2. 邮箱地址如何创建索引单选

• 直接创建索引

• 取前面5位做索引

• 取前面8位做索引

• 其它

3. 业务ID是varchar(32)，自己实现序列号保证唯一，是否适合做为主键？单选

• 适合做主键

• 不合适做主键

• 其它

4. 对于索引，以下说法哪些你认为是正确的？多选

• 后台需要经常查询的输入条件有10项，为加速查询，这10项都创建索引

• A经常单独查询，AB也经常组合查询，所以：A列建立独立索引，AB列创建组合索引

• 业务ID能保证唯一性，直接使用业务ID做为主键，而不是浪费空间创建自增主键

• 考虑分库分表和扩容，且业务ID能保证唯一性，直接使用业务ID做为主键，而不是浪费空间创建自增主键

• 表T有自增主键id，字段A、B、C三列的字义都是varchar32，A列是普通索引，B列和C列没有索引，select A，B from T where id = 5 和select B, C from T where id = 5 的性能是一样的

• 表T有自增主键id，字段A、B、C三列的字义都是varchar32，A列是独立索引，C列没有索引，select A，C from T where A = 5 和select A，B from T where A = 5的性能是一样的

• 表T有自增主键id，字段A、B、C三列的字义都是varchar32，A + B列是组合索引，C列没有索引，select A，C from T where A = 5 和select A，B from T where A = 5的性能是一样的

3. 索引数据结构基础知识

3.1 常见索引数据结构及特性

索引一般有3种类型：哈希表，数组，搜索树。（跳表等技术不在这里讨论）

哈希表：数据做哈希计算，如果有冲突，再使用链表解决。不适合做区间搜索（需要做全表扫描）。主要用于等值查找的场景，比如Memcached，Redis等。

数组：等值和区间查找优秀，插入慢。查找：二分法。插入：需要移动数据。适用：一次性初始化，不再更新，但是经常查询的场景。

搜索树：最常