如果能够保证业务代码不会写入重复数据，就可以继续往下看。 如果业务不能保证，那么必须创建唯一索引。

关于查询能力

普通索引和唯一索引在查询能力上是没有很大差别的。
如：select id from T where k=5
1、普通索引查找到满足条件的第一个记录（5，500）后需要查找下一个记录，直到碰到第一个不满足k=5条件的记录。
2、对于唯一索引，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止搜索。

InnoDB的数据按照数据页来读写，每一个数据页大小默认为16KB.
对于普通索引来说，查找k=5的记录，该记录所在的数据页都在内存里，无非就是多做一次
查找与判断下一条记录的操作。
当然，如果刚好k=5这个记录在数据页的最后一行，那么就得读取下一个数据页，这个会稍微复杂一点。

关于change buffer

需要更新一个数据页时，如果数据页在内存中就直接更新。
如果这个数据页在磁盘中，InnoDB会将这些更新操作缓存在change buffer中，这样就不需要从磁盘中读这个数据页了。
在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行change buffer中的关于这个页的操作。
change buffer 优点：
将更新操作先记录到change buffer ，减少读磁盘，语句执行速度会提升。
数据读入内存会占用buffer pool，使用change buffer可以避免占用内存，提高内存利用率
change buffer 缺点：
1、唯一索引的更新不能使用change buffer
2、change buffer的主要目的就是将记录变更动作缓存下来，在一个数据页merge之前，change buffer上记录越多，收益越大
如果一个业务的更新模式是写入后马上做查询，这样不会减少IO访问，反而增加了change buffer的维护代价。

关于写能力（基于change buffer）

普通索引在不需要立即读时候可以很好的应用change buffer，所以大部分场合建议使用普通索引。
如果在更新之后，马上伴随这个记录拆线呢，那么建议关闭change buffer。
redo log 主要节省的是随机写磁盘的IO消耗，change buffer 主要节省的则是随机读磁盘的IO消耗。