想象這樣一個場景，在設(shè)計一張用戶表時，每人的身份證號是唯一的，需要搜索。但由于身份證號字段較大，不好將其作為主鍵。在業(yè)務(wù)代碼已經(jīng)保證插入身份證唯一的情況下，可以選擇建立唯一索引和普通索引，這時該如何選擇呢？接下來，將從查詢和更新的執(zhí)行過程進行分析。

查詢過程

假設(shè) k 是表 t 上的索引，在搜索 select id from t where k=5 時，會先從 k 這棵 B+ 的樹根開始，按層搜索葉子節(jié)點，找到 k=5 的數(shù)據(jù)頁，然后在數(shù)據(jù)頁內(nèi)容進行二分法定位。

對于普通索引，找到 k=5 的記錄后，會繼續(xù)向下查找一個，直到碰到第一個不是 5 的記錄結(jié)束。

對于唯一索引，由于取值唯一，找到后直接停止。

由于 InnoDB 是按照數(shù)據(jù)頁為單位（數(shù)據(jù)頁默認 16 KB）進行讀寫的，在讀取一條數(shù)據(jù)時，會將整個數(shù)據(jù)頁整體讀到內(nèi)存。 在讀入內(nèi)存的數(shù)據(jù)頁中，如果包含 k=5 的記錄，在查詢的情況下，唯一索引比普通索引多了一次查找和判斷的過程，可以忽略。

如果 k=5 是當(dāng)前數(shù)據(jù)頁的最后一條，就需要在讀取下一個數(shù)據(jù)頁。但這發(fā)生的概率較低，也可以忽略。

所以總得來說，普通索引和唯一索引在查詢的過程中差異不大。

change buffer

在分析唯一索引和普通索引的影響前，先來認識一下 change buffer 這個結(jié)構(gòu)。

什么是 change buffer ?

在執(zhí)行更新操作時，如果要更新的數(shù)據(jù)頁在內(nèi)存中就直接更新，否則的話，在不影響數(shù)據(jù)一致性的前提下，InnoDB 會將更新操作緩存在 change buffer 中，從而省去了從磁盤讀取數(shù)據(jù)頁的過程。在下次查詢操作讀取到恰好需要更新的數(shù)據(jù)頁時，會將 change buffer 的更新語句執(zhí)行，寫入數(shù)據(jù)頁。將操作應(yīng)用到硬盤的過程叫 merge. 后臺線程會定期 merge 或 數(shù)據(jù)庫正常關(guān)閉時，也會進行 merge 操作。

merge 的執(zhí)行流程：

1. 從磁盤讀入老版本數(shù)據(jù)頁。
2. 從 change buffer中找出和該數(shù)據(jù)頁關(guān)聯(lián)的記錄，依次應(yīng)用，得到新版數(shù)據(jù)頁。
3. 寫 redo log，記錄數(shù)據(jù)的變更和 change buffer 的變更。

change buffer 實際上是可以持久化到硬盤中的數(shù)據(jù)，也就是說在內(nèi)存和硬盤上都 change buffer 的存在。change buffer 之前叫 insert buffer，開始只對 insert buffer 有優(yōu)化，后來加上了對 delete 和 update 的支持，進而改名叫 change buffer。

可以看到，先將更新操作記錄在 change buffer，減少了將磁盤數(shù)據(jù)頁讀取到內(nèi)存的過程，語句的執(zhí)行速度會有很明顯的提升。同時，將數(shù)據(jù)讀入內(nèi)存，會占用 buffer pool 內(nèi)存，所以減少讀操作，還提高了內(nèi)存使用率。

Buffer Pool 是內(nèi)存中的一個區(qū)域，InnoDB 在訪問表和索引數(shù)據(jù)時會在其中進行緩存。允許在內(nèi)存中直接更新經(jīng)常使用的數(shù)據(jù)，來加快處理速度。在一些專用的服務(wù)器上，會將 80% 的物理內(nèi)存分為 buffer pool.

可以通過 innodb_change_buffer_max_size 來設(shè)置 change buffer 占用 buffer pool 的大小。

change buffer 應(yīng)用場景？

如上面提到，change buffer 預(yù)先保存了更新記錄，減少了讀取數(shù)據(jù)頁的過程，從而提高性能。也就是說如果 change buffer 中針對不同的數(shù)據(jù)頁如果包含的更新記錄越多，其實收益也就越大。

因此對于寫多讀少的業(yè)務(wù)（更新完立即查詢）change buffer 發(fā)揮的作用也就越大。如常見的賬單類，日志類等系統(tǒng)。

如果業(yè)務(wù)是更新完立即查詢，雖然可以將更新記錄放在 change buffer 中，但由于之后要馬上查詢數(shù)據(jù)頁，所以會立即觸發(fā) merge 過程。這樣隨機訪問 IO 次數(shù)并不會減少，反而增加了 change buffer 的維護代價，起到反效果。

更新過程

對于唯一索引來說，所有的更新操作都需要判斷是否違反唯一性約束。所以必須把所需要的數(shù)據(jù)頁讀入內(nèi)存，然后直接更新就可以，不需要使用 change buffer. 所以 change buffer 只對普通索引有用。

具體分析下，對于一張表插入一個新記錄：

如果新記錄要更新的數(shù)據(jù)頁在內(nèi)存中：

對于唯一索引，找到合適的位置，判斷有沒有沖突，插入值，語句結(jié)束。

對于普通索引：找到位置，插入值，語句結(jié)束。

所以數(shù)據(jù)頁在內(nèi)存時，唯一和普通索引就差一個判斷的過程?？梢院雎?。

如果新記錄要更新的數(shù)據(jù)頁不在內(nèi)存中：

對于唯一索引，將數(shù)據(jù)頁讀入內(nèi)存，判斷沖突，插入，語句結(jié)束。

對于普通索引，將語句記錄在 change buffer 中，語句結(jié)束。

由于從磁盤到內(nèi)存涉及隨機 IO 訪問，是數(shù)據(jù)庫成本最高的操作之一。普通索引比唯一索引減少的讀入操作，可以有很好的性能提升。

唯一或普通索引的選擇

通過在查詢和更新方面，兩者的比較。我們知道，在查詢過程中，除了極特殊情況，其實兩者的差異并不大。

主要的差異是在更新過程中，要更新的數(shù)據(jù)頁并不在內(nèi)容中的情況。這時唯一索引，由于需要唯一性檢查，不能利用 change buffer. 多了從磁盤到內(nèi)容讀取數(shù)據(jù)的過程，其中涉及隨機 IO 的訪問，相對來說效率就低了。

所以如果業(yè)務(wù)需要更新不錯的性能，這時可以選用普通索引。當(dāng)然一切都是建立在能保證數(shù)據(jù)準(zhǔn)確性的前提下。

當(dāng)如果更新后來緊接著查詢操作，可以考慮關(guān)掉 change buffer. 其他的情況，change buffer 都能有很好的提升。

特別針對機械硬盤，change buffer 效果很顯著。

redo log 和 change buffer 的比較

InnoDB 中 redo log 的出現(xiàn)使其具有了 crash-safe 的能力，同時還提高了效率，通過 WAL 先寫日志，再寫磁盤。

而 change buffer 是節(jié)省了從磁盤讀入數(shù)據(jù)頁到內(nèi)存的隨機IO過程。

下面通過一條插入語句來分析下兩者間的關(guān)系：

mysql> insert into t(id,k) values(id1,k1),(id2,k2);

假設(shè) k 為普通索引，k1 所插入的數(shù)據(jù)頁在內(nèi)存中， k2 不在。

執(zhí)行插入操作時，主要涉及了圖中這四部分的內(nèi)容：

InnoDB buffer pool：內(nèi)存區(qū)域

redo log：日志

system table space(ibdata1):系統(tǒng)表空間

data(t.idb): 數(shù)據(jù)表空間

innodb_file_per_table 開啟時，表被創(chuàng)建在獨立的表空間下，否則的話被創(chuàng)建在系統(tǒng)的表空間下。

執(zhí)行過程如下：

1. k1 所在的 page1 在內(nèi)存中，直接更新內(nèi)存
2. k2 所在的 page2 不在內(nèi)存中，記錄在 change buffer.
3. 將 k1 和 k2 的操作記錄在 redo log.
4. 提交事務(wù)。
   

可以看到這條更新語句(包括插入，刪除，更新操作)執(zhí)行成本很低，兩次寫入內(nèi)存，1次順序?qū)懭氪疟P。虛線的操作，是后臺操作，不影響響應(yīng)時間。

再來看一條查詢語句：

select * from t where k in (k1, k2)

假設(shè)讀語句發(fā)生在更新語句不久，內(nèi)存數(shù)據(jù)還在，此時讀操作就和系統(tǒng)表空間和 redo log 無關(guān)。

執(zhí)行過程：

1. 讀取 k1 所在的 page1，在內(nèi)存中，直接返回。注意，并沒有讀磁盤上的數(shù)據(jù)，而且磁盤上的數(shù)據(jù)還有可能是之前的版本的。
2. 讀取 k2 所在的 page2，這時需要將 page2 從磁盤加載到內(nèi)存，并應(yīng)用 change buffer 的內(nèi)容，然后返回正確的結(jié)果。從這里也能看出，change buffer 不適用于更新完立馬去讀的情況。
   

總結(jié)下 redo log 和 change buffer 的關(guān)系：

存儲位置：change buffer 也會持久化在硬盤里，但保存在系統(tǒng)表空間 ibdata1 里。而 redo log 是單獨的文件。

記錄內(nèi)容：change buffer 記錄的是更新操作的內(nèi)容，而 redo log 記錄的是普通數(shù)據(jù)頁的修改和 change buffer 的改動。

同步磁盤過程：同步內(nèi)存中數(shù)據(jù)頁的修改時通過 merge 操作進行的，而不是根據(jù) redo log.

從更新的過程來看: redo log 將隨機寫磁盤的 IO 轉(zhuǎn)換成了順序?qū)?，?change buffer 則是節(jié)省了隨機讀磁盤的 IO 消耗。

如果服務(wù)器異常掉電，會不會導(dǎo)致 change buffer 丟失？

并不會，因為 change buffer 中的數(shù)據(jù)已經(jīng)被記錄到 redo log 中，所以不會丟失。

由于 change buffer 一部分數(shù)據(jù)在磁盤，一部分在內(nèi)存。對于在磁盤的數(shù)據(jù)已經(jīng) merge 所以不會丟失。
對于在內(nèi)存中的數(shù)據(jù)：

1. 如果 change buffer 寫入，但 redo log 未提交，binlog 未提交，事務(wù)會回滾，這部分數(shù)據(jù)不存在。
2. 如果 change buffer 寫入，redo log 寫入，binlog 寫入，并已提交，不會丟失。從 redo log 直接恢復(fù)。
3. 如果 change buffer 寫入，redo log 寫入但未 commit，binlog 寫入，從 binlog 恢復(fù) redo log 再恢復(fù) change buffer.

參考資料

Buffer Pool

以上就是MySQL唯一索引和普通索引選哪個？的詳細內(nèi)容，更多關(guān)于MySQL唯一索引和普通索引的資料請關(guān)注腳本之家其它相關(guān)文章！