MySQL 09 普通索引和唯一索引
唯一索引：字段值不能重复。
普通索引：字段值可以重复。
假设数据如下图，且字段k上的值都不重复：
接下来，从两种索引对查询语句和更新语句的性能影响来分析。
查询过程
假设查询语句为select id from T where k=5。那么首先会在字段k的索引树上找到k=5所在的数据页，然后在数据页内二分查找记录。对于普通索引和唯一索引，区别为：
普通索引，查找到满足条件的第一个记录后，会继续查找，直到找到第一个不满足
k=5的记录。唯一索引，找到第一个满足条件的记录后，就停止查找。
这个区别带来的性能差距其实是不大的。由于InnoDB的数据按数据页为单位进行读写，当找到k=5的那条记录时，它所在的数据页就都在内存里了，因此普通索引多进行的一次查找并没有多大开销。尽管有可能k=5刚好是数据页的最后一条记录，查找下一条记录需要新读取一页，但这种可能出现的概率很低，均摊到所有可能后成本可以忽略不计。
更新过程
在分析更新过程之前，先介绍change buffer。
当需要更新一个数据页，如果数据页在内存中，就直接更新；如果数据页在磁盘中，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在change buffer中。当下次查询需要访问该数据页，会将该数据页读入内存，执行change buffer中与该页有关的操作来保证数据逻辑的正确性。
change buffer在内存中，也会被持久化到磁盘上。
将change buffer中的操作应用到原数据页，得到最新结果的过程称为merge。除了访问这个数据页会触发merge，系统有后台线程会定期merge。在数据库正常关闭的过程中，也会执行merge操作。
可以看出，如果能将更新操作先记录在change buffer，减少读磁盘的次数，语句执行速度将会加快。而且，数据读入内存需要占用buffer pool，使用change buffer还能避免占用内存，提高内存利用率。
但并不是所有条件下都可以使用change buffer。对于唯一索引，所有更新操作都必须判断该操作是否违反唯一性约束，比如要插入(4,400)，就需要先判断表中是否已经有k=4的记录，因此每次更新都需要将数据页读入内存。而如果本身有读入内存的操作，那么直接更新内存即可，不需要再使用change buffer。而对普通索引，change buffer是可以使用的。
change buffer用的是buffer pool里的内存，不能无限增大。其大小可以通过innodb_change_buffer_max_size来动态设置，参数值表示占用buffer pool的百分比。
那么来看看，如果想要插入一条k=4的新纪录，InnoDB的处理流程：
对于唯一索引，找到3和5之间的位置，判断到没有冲突，插入值；
对于普通索引，找到3和5之间的位置，插入值。
看起来两者只相差一个判断，但若该记录要更新的目标页不在内存中，再对两者进行比较：
对于唯一索引，需要将数据页读入内存，判断到没有冲突，插入值；
对于普通索引，将更新记录在change buffer即可。
可以看到，这种情况下相差了一次随机磁盘IO，性能相差较大。
change buffer的使用场景
尽管change buffer能用于普通索引的场景，但并不是在所有情况下它都能起到加速作用。
这是由于merge是真正进行数据更新的时刻，而change buffer的主要目的就是将记录的变更动作缓存下来，所以在一个数据页merge前，change buffer记录的变更越多，收益越大。
对于写多读少的业务场景，页面写完后马上被访问的概率较小，意味着change buffer马上merge的概率较小，此时使用效果较好，场景业务模型如账单类、日志类系统。
而对于一个写入之后马上做查询的场景，merge的频率较高，这样随机访问IO的次数并不会减少，反而增加了change buffer的维护代价。因此，对于这种业务模式来说，change buffer反而起到了副作用。
索引选择和实践
回到之前的问题：如何选择普通索引和唯一索引。
经过上面的分析可以看到，两者在查询过程的能力几乎无差别，主要区别在更新过程。因此，建议尽量选择普通索引。如果是写入后马上查询的场景，建议关闭change buffer。
普通索引 + change buffer，对于数据量大的表的更新优化是比较明显的。特别地，在使用机械硬盘时，change buffer机制收益非常显著，因此使用机械硬盘时考虑加大change buffer。
change buffer和redo log
理解了change buffer的原理，可能会发现这和redo log有一些相似。
让我们回顾redo log的WAL机制：MySQL的更新用到了WAL（Write-Ahead Logging）技术，关键点就是先写日志，再写磁盘。具体来说，当有一条记录需要更新时，InnoDB引擎先将记录写到redo log并更新内存，这时更新就可以算完成了。之后，InnoDB会在适当的时候将这个操作记录更新到磁盘里。
接下来，使用一个例子来区分这两个概念。假设要在表上执行下面这个插入语句：
insert into t(id,k) values(id1,k1),(id2,k2); |
假设在k索引树找到位置后，k1所在的数据页在内存中，而k2所在的数据页不在内存中。下图是带change buffer的更新状态图：
分析这条更新语句：
发现Page 1在内存中，直接更新内存；
发现Page 2没有在内存中，就在内存的change buffer区域，记录“我要往Page 2插入一行”这个信息；
将上述两个动作记入redo log。
做完上述动作，事务就完成了。可以发现，对于该次更新，只是写了两次内存+一次磁盘。图中的虚线箭头是后台操作，不会影响更新的响应时间。
那么此次更新之后的查询请求，会怎么处理呢？
比如要执行select * from t where k in (k1,k2)，其读请求的流程图如下：
分析这条查询语句：
读Page 1时，直接从内存返回。
读Page 2时，需要先将Page 2从磁盘读入内存，然后应用change buffer，生成一个正确版本并返回结果。
因此，如果简单对比change buffer和redo log在提升更新性能上的收益的话：
redo log主要节省了随机写磁盘的IO消耗，将随机写转为了顺序写；
change buffer节省了随机读磁盘的IO消耗。
最后，做一个思考：如果某次写入使用了change buffer，如果之后主机异常重启，是否会丢失change buffer和数据？
答案是不会，因为在写完change buffer后，会把该动作也记录到redo log后，之后崩溃恢复也可以通过redo log找回。