6.唯一索引和普通索引
change buffer和redo log的区别
很容易被混淆的两个概念，都是为了减少磁盘的IO操作，但是在更新一条语句的时候，其实是有先后顺序的，也就是看此数据叶在不在内存中，
如果数据叶在内存中，那么更新操作会先在redo log中更改数据，然后等空闲再写磁盘，这样减少写磁盘。
但是如果数据叶不在内存中，会先将操作指令存入change buffer（待更改的缓冲区）中，这时会先不更新数据，而是等到做查询数据的时候的时候，数据叶读到内存中后，再从change buffer拿到指令，并在内存中更新。等空闲时再刷到磁盘，
所以是否会change buffer是有前提条件，也就是该数据叶是否在内存中。先redolog 然后在判断是否change buffer。
所以，如果要简单地对比这两个机制在提升更新性能上的收益的话，redo log 主要节省的是随机写磁盘的 IO 消耗（转成顺序写），而 change buffer 主要节省的则是随机读磁盘的 IO 消耗。
并且change buffer的作用是可以拆分一条语句的，比如说在插入一条数据的时候，主键和其他唯一索引的值不会做change buffer，但是其他字段是可以走change buffer的。
选择普通索引还是唯一索引？
对于查询过程来说：
a、普通索引，查到满足条件的第一个记录后，继续查找下一个记录，知道第一个不满足条件的记录
b、唯一索引，由于索引唯一性，查到第一个满足条件的记录后，停止检索
但是，两者的性能差距微乎其微。因为InnoDB根据数据页来读写的。
对于更新过程来说：
概念：change buffer
当需要更新一个数据页，如果数据页在内存中就直接更新，如果不在内存中，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在change buffer中。下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中的与这个页有关的操作。
change buffer是可以持久化的数据。在内存中有拷贝，也会被写入到磁盘上
purge:将change buffer中的操作应用到原数据页上，得到最新结果的过程，成为purge
访问这个数据页会触发purge，系统有后台线程定期purge，在数据库正常关闭的过程中，也会执行purge
唯一索引的更新不能使用change buffer
change buffer用的是buffer pool里的内存，change buffer的大小，可以通过参数innodb_change_buffer_max_size来动态设置。这个参数设置为50的时候，表示change buffer的大小最多只能占用buffer pool的50%。
将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。
change buffer 因为减少了随机磁盘访问，所以对更新性能的提升很明显。
change buffer使用场景
在一个数据页做purge之前，change buffer记录的变更越多，收益就越大。
对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer,但之后由于马上要访问这个数据页，会立即触发purge过程。
这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来说，change buffer反而起到了副作用。
索引的选择和实践：
尽可能使用普通索引。
redo log主要节省的是随机写磁盘的IO消耗(转成顺序写)，而change buffer主要节省的则是随机读磁盘的IO消耗。