在不同的业务场景下，应该选择普通索引，还是唯一索引？
对于查询过程来说：
普通索引：查到满足条件的第一个记录后，继续查找下一个记录，直到第一个不满足条件的记录
唯一索引：由于索引唯一性，查到第一个满足条件的记录后，停止检索
但是，两者的性能差距微乎其微。因为InnoDB根据数据页来读写的。
对于更新过程来说：
change buffer
当需要更新一个数据页，如果数据页在内存中就直接更新，如果不在内存中，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在change buffer中。下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中的与这个页有关的操作。
change buffer是可以持久化的数据。在内存中有拷贝，也会被写入到磁盘上
merge:将change buffer中的操作应用到原数据页上，得到最新结果的过程
访问这个数据页会触发merge，系统有后台线程定期merge，在数据库正常关闭的过程中，也会执行merge。
唯一索引的更新不能使用change buffer
change buffer用的是buffer pool里的内存，change buffer的大小，可以通过参数innodb_change_buffer_max_size来动态设置。这个参数设置为50的时候，表示change buffer的大小最多只能占用buffer pool的50%。
将数据从磁盘读入内存涉及随机IO的访问，是数据库里面成本最高的操作之一。更新操作的时候，如果目标不在内存中，唯一索引需要IO将数据读入内存，普通索引只要更新到change buffer即可。因此减少了随机磁盘访问，所以对更新性能的提升很明显。
change buffer使用场景
在一个数据页做merge之前，change buffer记录的变更越多，收益就越大。
对于写多读少的业务来说，页面在写完以后马上被访问到的概率比较小，此时change buffer的使用效果最好。这种业务模型常见的就是账单类、日志类的系统。
反过来，假设一个业务的更新模式是写入之后马上会做查询，那么即使满足了条件，将更新先记录在change buffer,但之后由于马上要访问这个数据页，会立即触发merge过程。
这样随机访问IO的次数不会减少，反而增加了change buffer的维护代价。所以，对于这种业务模式来说，change buffer反而起到了副作用。
merge 的执行流程：从磁盘读入数据页到内存（老版本的数据页）；从 change buffer 里找出这个数据页的 change buffer 记录 (可能有多个），依次应用，得到新版数据页；写 redo log。这个 redo log 包含了数据的变更和 change buffer 的变更。
索引的选择和实践：
尽可能使用普通索引。如果更新后要马上查询该记录，则应该关闭change buffer。
redo log主要节省的是随机写磁盘的IO消耗(转成顺序写)，而change buffer主要节省的则是随机读磁盘的IO消耗。
参考资料：丁奇，MySQL实战45讲
部分内容来自网络，如有侵权请联系作者删除。
