【MySQL】9｜普通索引和唯一索引怎么选

先说结论：普通索引的效率比唯一索引要好，除非业务上有要求，不然建议使用普通索引

1、查询过程

例：执行的查询语句是 select id from T where k=5；这个查询语句在索引树上查找的过程，先是通过B+树从树根开始，按层搜索到叶子节点，然后可以认为数据页内部通过二分法来定位记录。

• 普通索引，查到满足条件的第一个记录后，需要查找下一个记录，直到碰到第一个不满足条件的记录。
• 唯一索引，由于定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索。
• 但是，这个不同带来的性能差距，微乎其微。

InnoDB的数据是按数据页为单位来读写的。也就是说，当需要读第一条记录的时候，并不是将这个记录本身从磁盘中读取出来，而是以页为单位，将其整体读入内存。在InnoDB中，每个数据页的大小默认是16KB。

因此当需要查找下一个记录的时候，直接在内存中判断就好了，多一次指针寻找和计算。

对于当前记录为数据页的最后一条记录时，必须要取下一页数据，这个操作会稍微复杂一点。

但是对于整形字段，一个数据页可以放近千个key，因此出现这种情况的概率会很低。所以，在计算平均性能影响差异时，仍可以认为这个操作成本对于现在的CPU来说可以忽略不计。

2、更新过程

为了说明普通索引和唯一索引对更新语句性能的影响这个问题，需要先介绍一下change buffer。

change buffer 的概念

• 当需要更新一个数据页时，如果数据页在内存中就直接更新。
• 如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。
• 在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer 中与这个页有关的操作。

需要说明的是，虽然名字叫做 change buffer，实际上它是可以持久化的数据。也就是说，change buffer 在内存中有拷贝，也会被写入到磁盘上。

将 change buffer 中的操作应用到原数据页，得到最新结果的过程称为 merge。除了访问这个数据页会触发 merge外，系统有后台线程会定期merge。在数据库正常关闭的过程中，也会执行merge操作。

显然，如果能够将更新操作先记录在change buffer，减少读磁盘，语句的执行速度会得到明显的提升。而且，虽然change buffer 也是需要占用内存，但相比于数据页来说（默认16k），避免了占用内存。

什么条件下可以使用change buffer？

• 唯一索引不能使用。因为所有的更新操作都要先判断这个操作是否违反唯一性约束。需要将数据页读入内存才能判断，既然已经读入内存了，直接更新内存会更快，就必要使用了。
• 普通索引可以使用。
• change buffer 用的是 buffer pool 中的内存，可以通过 innodb_change_buffer_max_size 来动态设置。这个参数值为50的时候，表示change_buffer的大小最多只能占用 buffer pool的50%。

3、插入过程

比如要在表中插入一个新数据，InnoDB是这样处理的：

第一种情况是，这个记录要插入的目标页在内存中，流程如下：

• 唯一索引，找到记录所在区间，判断有没有冲突，如果没有，插入这个值，语句执行结束
• 普通索引，找到记录所在区间，插入这个值，语句执行结束

这种情况，普通索引和唯一索引对插入语句性能影响的差别很小。

第二种情况是，这个记录要插入的目标页不在内存中，流程如下：

• 唯一索引，需要将数据页读入内存，判断有没有冲突，插入这个值，语句执行结束
• 普通索引，直接更新在change buffer 中，语句执行结束

将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。change buffer 因为减少了随机磁盘访问，所以对性能的提升是会很明显的。

4、使用场景

根据以上分析，change buffer 只限于用在普通索引的场景下，不适用于唯一索引。但是并不是所有场景都适用。

• 对于写多读少的业务来说，使用change buffer 的效果最好。例如账单类、日志类系统。
• 对于写入后立马做查询的场景，即使满足了条件，将更新先记录在 change buffer，但之后由于马上要访问这个数据页，会立即触发merge过程。这样随机访问IO的次数不会减少，反而增加了 change buffer 的维护代价。所以对于这种模式来说，change buffer 反而起到了副作用。

5、索引选择

综合上述描述，这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，建议尽量选择普通索引。当然如果是业务需要，还是要以业务为主。

如果所有的更新后面，都马上伴随这对这个记录的查询，那么应该关闭 change buffer。在其他情况下，change buffer 都能提升更新性能。

6、change buffer 和 redo log

这两个都是通过减少随机读写，提升性能，概念上容易混淆。下面是MySQL官网的InnoDB（5.7版本）架构图

MySQL架构图

可以发现，这两个是处于不同的结构中。我们以插入数据为例：

mysql> insert into t(id,k) values(id1,k1),(id2,k2);

假设当前k索引树的状态，查找到位置后，k1所在的数据页在内存（InnoDB buffer pool）中，k2所在的数据页不在内存中。如下图：

更新示意图

分析这条更新语句，它涉及到四个部分：内存、redo log(ib_log_fileX)、数据表空间(t.ibd)、系统表空间(ibdata1)

更新步骤：

1. Page 1在内存中，直接更新内存
2. Page2 不在内存中，就在内存的change buffer 区域，记录下“我要往Page2 插入一行”这个信息
3. 将上述两个动作计入 redo log 中（图中 3 和 4）

做完上面这些，事务就可以完成了。执行这条更新语句的成本很低，就是写了两处内存（图中1和2），然后写了一处磁盘（图中3和4一起写入的），而且还是顺序写。

同时，图中的两个虚线箭头，是后台操作，不影响更新的响应时间。

如果此时，正好要查询数据，比如select * from t where k in (k1,k2)，要怎么处理呢？

如果读语句发生在更新语句后不久，内存中的数据都还在。

• 读Page1的时候，因为数据在内存中，就直接从内存返回
• 读Page2的时候，需要把 Page2从磁盘读入内存中，然后应用 change buffer 里面的操作日志，生成一个正确的版本并返回结果

可以直到，直到需要读Page2 的时候，这个数据页才会被读入内存。

所以，如果要简单地对比这两个机制在提升更新性能上的收益的话，redo log 主要节省的是随机读写磁盘 IO 消耗（转成顺序写），而change buffer 主要节省的则是随机读磁盘的IO消耗。