如果能夠保證業務代碼不會寫入重復數據，就可以繼續往下看。 如果業務不能保證，那么必須創建唯一索引。

關于查詢能力

普通索引和唯一索引在查詢能力上是沒有很大差別的。
如：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消耗。