前言

本文我们将会从针对普通索引与唯一索引的增删改查的具体执行流程，来看看效率的对比。以便让我们在实际业务开发中可以进行更好的选择。

一、普通索引和唯一索引介绍

普通索引：
普通索引就是建立在普通字段上的索引，即不要求字段为主键，也不要求字段为UNIQUE。
在创建表时，创建普通索引的方式如下：

create table table_name (...index(index_column_1,index_column_2,...));

建表后，如果要创建普通索引，可以使用如下这条命令：

create index index_name on table_name(index_column_1,index_column_2,...);

唯一索引：
唯一索引建立在UNIQUE字段上的索引，一张表可以有多个唯一索引，索引列的值必须唯一，但是允许有空值。
在创建表时，创建唯一索引的方式如下：

create table table_name(...unique key(index_column_1,index_column_2,...));

建表后，如果要创建唯一索引，可以使用下面这条命令：

create unique index index_name on table_name(index_column_1,index_column_2,...);

明白了基本概念，接着我们对执行具体SQL语句的时候，看看用这两个索引的具体执行流程是啥，性能咋样。

二、查询语句的比较

我们也是通过具体的例子来进行分析。
如果我们执行如下查询语句：

select id from t_table where k=5;

id为主键，k为普通索引或者唯一索引。

这个查询语句在索引树上查找的过程，先是通过B+树从树根开始，按层搜索到叶子节点的指向的数据页，然后数据页内部通过二分法来定位记录。接下来我们，看下当确定到第一条记录后，对于普通索引和唯一索引会有什么不同：

普通索引：查找到满足条件的第一个记录后，需要查找下一个记录，直到碰到第一个不满足k=5条件的记录；
唯一索引：由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止继续检索

那这个不同会带来多大的性能差异呢？其实是微乎其微的。

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

所以，当找到k=5的记录的时候，它所在的数据页就都在内存里了。那么，对于普通索引来说，要多做的那一次“查找和判断下一条记录”的操作，就只需要一次指针寻找和一次计算。虽然有可能，k=5这个记录刚好是这个数据页的最后一个记录，那么读取下一个记录，就要读取下一个数据页，设计到对磁盘io的操作，性能可能会降低，但是出现这种情况的概率很低，所以通过计算平均性能差异可以忽略不计。

由此可见，说到底用这两个不同查询语句的区别就是，普通索引找到记录后，还会往后接着遍历，直到记录不满足为止。而唯一索引查询到第一个满足条件的记录后，就直接停止检索了。

三、更新语句的比较

在介绍之前，我们先介绍下基本的更新过程。再介绍这些之前，我们先连接两个概念：

buffer pool：MySQL 的 Buffer Pool
change buffer:它是内存中的一块区域，保存在InnoDB的buffer pool中，在磁盘上也有对应的持久化空间（change buffer在内存中有拷贝，也会被写入到磁盘上），在系统表空间ibdata中。它在MySQL中的change buffer信息如下，默认值是25，代表它的大小最大只能占用到InnoDB buffer pool的25%大小，如下所示：

show variables like "%change%";

在这里插入图片描述

明白之后，我们再来看下，更新流程的基本操作：
当更新数据页的时候，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中
的话，在不影响数据一致性的前提下，InooDB会将这些更新操作缓存在change buffer中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正
确性。这样做主要有两个好处：

第一个：将原本2次的磁盘访问，整合成1次磁盘访问，并且能够保证数据的一致性；
第二个：数据页读入内存是需要占用内存空间的。如果仅仅是为了更新而把数据页读入到内存，这未免会造成浪费。因此，上述方法能够避免内存的使用，提高内存的利用率。

将change buffer中的操作应用到原数据页，得到最新结果过程称为merge。触发merge的有以下几种情况：

访问这个数据页的时候
后台线程会定期merge
数据库正常关闭的过程中

明白了使用使用change buffer效率的高效。接下来我们看看是不是普通索引和唯一索引都可以使用呢？
先告诉结论吧，唯一索引不能使用change buffer，普通索引会使用。 接下来分析下原因：
对于唯一索引来说，所有的更新操作都要先判断这个操作是否违反唯一性约束。 比如，要插入
(4,400)这个记录，就要先判断现在表中是否已经存在k=4的记录，而这必须要将数据页读入内存
才能判断。如果都已经读入到内存了，那直接更新内存会更快，就没必要使用change buffer
了。

明白了普通索引和唯一索引的更新流程，接下来我们以一个具体的例子，再来看看它们之间的性能差异：
如果要在上述所说的表中插入一个如新记录(4,400)的话。我们分别使用的是普通索引和唯一索引：
如果记录要更新的目标页在内存中，处理流程如下：

唯一索引：找到3和5之间的位置，判断有没有冲突，插入这个值，语句执行结束；
普通索引：找到3和5之间的位置，插入这个值，语句执行结束

这样看来，普通索引和唯一索引对更新语句性能影响的差别，只是一个判断，只会耗费微小的CPU时间。

如果这个记录更新的目标不在内存中，处理流程如下：

唯一索引：将数据页读入内存，判断到没有冲突，插入这个值，语句执行结束；
普通索引：将更新记录在change buffer，语句执行结束

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

通过上述，我们了解了change buffer的具体功效，明白了change buffer只限用在普通索引的场景下，而不适用于唯一索引。接下来我们对change buffer的使用场景进行深度分析，看看对于普通索引的所有场景，使用change buffer都可以起到加速作用吗？
在一些写多读少的业务中，change buffer能够发挥很好的作用。它可以将多次对磁盘的操作，合并成一次merge操作，从而提高MySQL的性能，一次性merge的操作越多，收益就越大。

但是需要注意，如果你的数据写入之后。立马会读取(也就意味着需要从磁盘读取到内存)，那么建议不要使用change buffer，因为在这种情况下，使用change buffer不会减低IO次数，反而多了change buffer的维护开销。

了解了这些之后，我们还要落实到实处，看看在实际中是怎么进行选择的。