今天的正文開始前，我要特意感謝一下評論區幾位留下高質量留言的同學。
用戶名是 @某、人 的同學，對文章的知識點做了梳理，然后提了關於事務可見性的問題，就是先啟動但是后提交的事務，對數據可見性的影響。@夏日雨同學也提到了這個問題，我在置頂評論中回復了，今天的文章末尾也會再展開說明。@Justin和@倪大人兩位同學提了兩個好問題。
對於能夠引發更深一步思考的問題，我會在回復的內容中寫上“好問題”三個字，方便你搜索，你也可以去看看他們的留言。
非常感謝大家很細致地看文章，並且留下了那么多和很高質量的留言。知道文章有給大家帶來一些新理解，對我來說是一個很好的鼓勵。同時，也讓其他認真看評論區的同學，有機會發現一些自己還沒有意識到的、但可能還不清晰的知識點，這也在總體上提高了整個專欄的質量。再次謝謝你們。
好了，現在就回到我們今天的正文內容。
在前面的基礎篇文章中，我給你介紹過索引的基本概念，相信你已經了解了唯一索引和普通索引的區別。今天我們就繼續來談談，在不同的業務場景下，應該選擇普通索引，還是唯一索引？
假設你在維護一個市民系統，每個人都有一個唯一的身份證號，而且業務代碼已經保證了不會寫入兩個重復的身份證號。如果市民系統需要按照身份證號查姓名，就會執行類似這樣的SQL語句：
select name from CUser where id_card = 'xxxxxxxyyyyyyzzzzz';
所以，你一定會考慮在id_card字段上建索引。
由於身份證號字段比較大，我不建議你把身份證號當做主鍵，那么現在你有兩個選擇，要么給id_card字段創建唯一索引，要么創建一個普通索引。如果業務代碼已經保證了不會寫入重復的身份證號，那么這兩個選擇邏輯上都是正確的。
現在我要問你的是，從性能的角度考慮，你選擇唯一索引還是普通索引呢？選擇的依據是什么呢？
簡單起見，我們還是用第4篇文章《深入淺出索引（上）》中的例子來說明，假設字段 k 上的值都不重復。
接下來，我們就從這兩種索引對查詢語句和更新語句的性能影響來進行分析。
查詢過程
假設，執行查詢的語句是 select id from T where k=5。這個查詢語句在索引樹上查找的過程，先是通過B+樹從樹根開始，按層搜索到葉子節點，也就是圖中右下角的這個數據頁，然后可以認為數據頁內部通過二分法來定位記錄。
- 對於普通索引來說，查找到滿足條件的第一個記錄(5,500)后，需要查找下一個記錄，直到碰到第一個不滿足k=5條件的記錄。
- 對於唯一索引來說，由於索引定義了唯一性，查找到第一個滿足條件的記錄后，就會停止繼續檢索。
那么，這個不同帶來的性能差距會有多少呢？答案是，微乎其微。
你知道的，InnoDB的數據是按數據頁為單位來讀寫的。也就是說，當需要讀一條記錄的時候，並不是將這個記錄本身從磁盤讀出來，而是以頁為單位，將其整體讀入內存。在InnoDB中，每個數據頁的大小默認是16KB。
因為引擎是按頁讀寫的，所以說，當找到k=5的記錄的時候，它所在的數據頁就都在內存里了。那么，對於普通索引來說，要多做的那一次“查找和判斷下一條記錄”的操作，就只需要一次指針尋找和一次計算。
當然，如果k=5這個記錄剛好是這個數據頁的最后一個記錄，那么要取下一個記錄，必須讀取下一個數據頁，這個操作會稍微復雜一些。
但是，我們之前計算過，對於整型字段，一個數據頁可以放近千個key，因此出現這種情況的概率會很低。所以，我們計算平均性能差異時，仍可以認為這個操作成本對於現在的CPU來說可以忽略不計。
更新過程
為了說明普通索引和唯一索引對更新語句性能的影響這個問題，我需要先跟你介紹一下change buffer。
當需要更新一個數據頁時，如果數據頁在內存中就直接更新，而如果這個數據頁還沒有在內存中的話，在不影響數據一致性的前提下，InooDB會將這些更新操作緩存在change buffer中，這樣就不需要從磁盤中讀入這個數據頁了。在下次查詢需要訪問這個數據頁的時候，將數據頁讀入內存，然后執行change buffer中與這個頁有關的操作。通過這種方式就能保證這個數據邏輯的正確性。
需要說明的是，雖然名字叫作change buffer，實際上它是可以持久化的數據。也就是說，change buffer在內存中有拷貝，也會被寫入到磁盤上。
將change buffer中的操作應用到原數據頁，得到最新結果的過程稱為merge。除了訪問這個數據頁會觸發merge外，系統有后台線程會定期merge。在數據庫正常關閉（shutdown）的過程中，也會執行merge操作。
顯然，如果能夠將更新操作先記錄在change buffer，減少讀磁盤，語句的執行速度會得到明顯的提升。而且，數據讀入內存是需要占用buffer pool的，所以這種方式還能夠避免占用內存，提高內存利用率。
那么，什么條件下可以使用change buffer呢？
對於唯一索引來說，所有的更新操作都要先判斷這個操作是否違反唯一性約束。比如，要插入(4,400)這個記錄，就要先判斷現在表中是否已經存在k=4的記錄，而這必須要將數據頁讀入內存才能判斷。如果都已經讀入到內存了，那直接更新內存會更快，就沒必要使用change buffer了。
因此，唯一索引的更新就不能使用change buffer，實際上也只有普通索引可以使用。
change buffer用的是buffer pool里的內存，因此不能無限增大。change buffer的大小，可以通過參數innodb_change_buffer_max_size來動態設置。這個參數設置為50的時候，表示change buffer的大小最多只能占用buffer pool的50%。
現在，你已經理解了change buffer的機制，那么我們再一起來看看如果要在這張表中插入一個新記錄(4,400)的話，InnoDB的處理流程是怎樣的。
第一種情況是，這個記錄要更新的目標頁在內存中。這時，InnoDB的處理流程如下：
- 對於唯一索引來說，找到3和5之間的位置，判斷到沒有沖突，插入這個值，語句執行結束；
- 對於普通索引來說，找到3和5之間的位置，插入這個值，語句執行結束。
這樣看來，普通索引和唯一索引對更新語句性能影響的差別，只是一個判斷，只會耗費微小的CPU時間。
但，這不是我們關注的重點。
第二種情況是，這個記錄要更新的目標頁不在內存中。這時，InnoDB的處理流程如下：
- 對於唯一索引來說，需要將數據頁讀入內存，判斷到沒有沖突，插入這個值，語句執行結束；
- 對於普通索引來說，則是將更新記錄在change buffer，語句執行就結束了。
將數據從磁盤讀入內存涉及隨機IO的訪問，是數據庫里面成本最高的操作之一。change buffer因為減少了隨機磁盤訪問，所以對更新性能的提升是會很明顯的。
之前我就碰到過一件事兒，有個DBA的同學跟我反饋說，他負責的某個業務的庫內存命中率突然從99%降低到了75%，整個系統處於阻塞狀態，更新語句全部堵住。而探究其原因后，我發現這個業務有大量插入數據的操作，而他在前一天把其中的某個普通索引改成了唯一索引。
change buffer的使用場景
通過上面的分析，你已經清楚了使用change buffer對更新過程的加速作用，也清楚了change buffer只限於用在普通索引的場景下，而不適用於唯一索引。那么，現在有一個問題就是：普通索引的所有場景，使用change buffer都可以起到加速作用嗎？
因為merge的時候是真正進行數據更新的時刻，而change buffer的主要目的就是將記錄的變更動作緩存下來，所以在一個數據頁做merge之前，change buffer記錄的變更越多（也就是這個頁面上要更新的次數越多），收益就越大。
因此，對於寫多讀少的業務來說，頁面在寫完以后馬上被訪問到的概率比較小，此時change buffer的使用效果最好。這種業務模型常見的就是賬單類、日志類的系統。
反過來，假設一個業務的更新模式是寫入之后馬上會做查詢，那么即使滿足了條件，將更新先記錄在change buffer，但之后由於馬上要訪問這個數據頁，會立即觸發merge過程。這樣隨機訪問IO的次數不會減少，反而增加了change buffer的維護代價。所以，對於這種業務模式來說，change buffer反而起到了副作用。
索引選擇和實踐
回到我們文章開頭的問題，普通索引和唯一索引應該怎么選擇。其實，這兩類索引在查詢能力上是沒差別的，主要考慮的是對更新性能的影響。所以，我建議你盡量選擇普通索引。
如果所有的更新后面，都馬上伴隨着對這個記錄的查詢，那么你應該關閉change buffer。而在其他情況下，change buffer都能提升更新性能。
在實際使用中，你會發現，普通索引和change buffer的配合使用，對於數據量大的表的更新優化還是很明顯的。
特別地，在使用機械硬盤時，change buffer這個機制的收效是非常顯著的。所以，當你有一個類似“歷史數據”的庫，並且出於成本考慮用的是機械硬盤時，那你應該特別關注這些表里的索引，盡量使用普通索引，然后把change buffer 盡量開大，以確保這個“歷史數據”表的數據寫入速度。
change buffer 和 redo log
理解了change buffer的原理，你可能會聯想到我在前面文章中和你介紹過的redo log和WAL。
在前面文章的評論中，我發現有同學混淆了redo log和change buffer。WAL 提升性能的核心機制，也的確是盡量減少隨機讀寫，這兩個概念確實容易混淆。所以，這里我把它們放到了同一個流程里來說明，便於你區分這兩個概念。
備注：這里，你可以再回顧下第2篇文章《日志系統：一條SQL更新語句是如何執行的？》中的相關內容。
現在，我們要在表上執行這個插入語句：
mysql> insert into t(id,k) values(id1,k1),(id2,k2);
這里，我們假設當前k索引樹的狀態，查找到位置后，k1所在的數據頁在內存(InnoDB buffer pool)中，k2所在的數據頁不在內存中。如圖2所示是帶change buffer的更新狀態圖。
分析這條更新語句，你會發現它涉及了四個部分：內存、redo log（ib_log_fileX）、 數據表空間（t.ibd）、系統表空間（ibdata1）。
這條更新語句做了如下的操作（按照圖中的數字順序）：
-
Page 1在內存中，直接更新內存；
-
Page 2沒有在內存中，就在內存的change buffer區域，記錄下“我要往Page 2插入一行”這個信息
-
將上述兩個動作記入redo log中（圖中3和4）。
做完上面這些，事務就可以完成了。所以，你會看到，執行這條更新語句的成本很低，就是寫了兩處內存，然后寫了一處磁盤（兩次操作合在一起寫了一次磁盤），而且還是順序寫的。
同時，圖中的兩個虛線箭頭，是后台操作，不影響更新的響應時間。
那在這之后的讀請求，要怎么處理呢？
比如，我們現在要執行 select * from t where k in (k1, k2)。這里，我畫了這兩個讀請求的流程圖。
如果讀語句發生在更新語句后不久，內存中的數據都還在，那么此時的這兩個讀操作就與系統表空間（ibdata1）和 redo log（ib_log_fileX）無關了。所以，我在圖中就沒畫出這兩部分。
從圖中可以看到：
-
讀Page 1的時候，直接從內存返回。有幾位同學在前面文章的評論中問到，WAL之后如果讀數據，是不是一定要讀盤，是不是一定要從redo log里面把數據更新以后才可以返回？其實是不用的。你可以看一下圖3的這個狀態，雖然磁盤上還是之前的數據，但是這里直接從內存返回結果，結果是正確的。
-
要讀Page 2的時候，需要把Page 2從磁盤讀入內存中，然后應用change buffer里面的操作日志，生成一個正確的版本並返回結果。
可以看到，直到需要讀Page 2的時候，這個數據頁才會被讀入內存。
所以，如果要簡單地對比這兩個機制在提升更新性能上的收益的話，redo log 主要節省的是隨機寫磁盤的IO消耗（轉成順序寫），而change buffer主要節省的則是隨機讀磁盤的IO消耗。
小結
今天，我從普通索引和唯一索引的選擇開始，和你分享了數據的查詢和更新過程，然后說明了change buffer的機制以及應用場景，最后講到了索引選擇的實踐。
由於唯一索引用不上change buffer的優化機制，因此如果業務可以接受，從性能角度出發我建議你優先考慮非唯一索引。
最后，又到了思考題時間。
通過圖2你可以看到，change buffer一開始是寫內存的，那么如果這個時候機器掉電重啟，會不會導致change buffer丟失呢？change buffer丟失可不是小事兒，再從磁盤讀入數據可就沒有了merge過程，就等於是數據丟失了。會不會出現這種情況呢？
你可以把你的思考和觀點寫在留言區里，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一起閱讀。
補充：
評論區大家對“是否使用唯一索引”有比較多的討論，主要是糾結在“業務可能無法確保”的情況。這里，我再說明一下：
- 首先，業務正確性優先。咱們這篇文章的前提是“業務代碼已經保證不會寫入重復數據”的情況下，討論性能問題。如果業務不能保證，或者業務就是要求數據庫來做約束，那么沒得選，必須創建唯一索引。這種情況下，本篇文章的意義在於，如果碰上了大量插入數據慢、內存命中率低的時候，可以給你多提供一個排查思路。
- 然后，在一些“歸檔庫”的場景，你是可以考慮使用唯一索引的。比如，線上數據只需要保留半年，然后歷史數據保存在歸檔庫。這時候，歸檔數據已經是確保沒有唯一鍵沖突了。要提高歸檔效率，可以考慮把表里面的唯一索引改成普通索引。
上期問題時間
上期的問題是：如何構造一個“數據無法修改”的場景。評論區里已經有不少同學給出了正確答案，這里我再描述一下。
這樣，session A看到的就是我截圖的效果了。
其實，還有另外一種場景，同學們在留言區都還沒有提到。
這個操作序列跑出來，session A看的內容也是能夠復現我截圖的效果的。這個session B’啟動的事務比A要早，其實是上期我們描述事務版本的可見性規則時留的彩蛋，因為規則里還有一個“活躍事務的判斷”，我是准備留到這里再補充的。
當我試圖在這里講述完整規則的時候，發現第8篇文章《事務到底是隔離的還是不隔離的？》中的解釋引入了太多的概念，以致於分析起來非常復雜。
因此，我重寫了第8篇，這樣我們人工去判斷可見性的時候，才會更方便。【看到這里，我建議你能夠再重新打開第8篇文章並認真學習一次。如果學習的過程中，有任何問題，也歡迎你給我留言】
用新的方式來分析session B’的更新為什么對session A不可見就是：在session A視圖數組創建的瞬間，session B’是活躍的，屬於“版本未提交，不可見”這種情況。
業務中如果要繞過這類問題，@約書亞提供了一個“樂觀鎖”的解法，大家可以去上一篇的留言區看一下。