場景

1、維護一個市民系統，有一個欄位為身份證號

2、業務程式碼能保證不會寫入兩個重複的身份證號（如果業務無法保證，可以依賴資料庫的唯一索引來進行約束）

3、常用SQL查詢語句：SELECT name FROM CUser WHERE id_card = 'XXX'

4、建立索引

• 身份證號比較大，不建議設定為主鍵
• 從效能角度出發，選擇普通索引還是唯一索引？

假設欄位k上的值都不重複

查詢過程

1、查詢語句：SELECT id FROM T WHERE k=5

2、查詢過程

• 通過B+樹從樹根開始，按層搜尋到葉子節點，即上圖中右下角的資料頁
• 在資料頁內部通過二分法來定位具體的記錄

3、針對普通索引

• 查詢滿足條件的第一個記錄(5,500)，然後查詢下一個記錄，直到找到第一個不滿足k=5的記錄

4、針對唯一索引

• 由於索引定義了唯一性，查詢到第一個滿足條件的記錄後，就會停止繼續查詢

效能差異

1、效能差異：微乎其微

2、InnoDB的資料是按照資料頁為單位進行讀寫的，預設為16KB

3、當需要讀取一條記錄時，並不是將這個記錄本身從磁碟讀出來，而是以資料頁為單位進行讀取的

4、當找到k=5的記錄時，它所在的資料頁都已經在記憶體裡了

5、對於普通索引而言，只需要多一次指標尋找和多一次計算 – CPU消耗很低

• 如果k=5這個記錄恰好是所在資料頁的最後一個記錄，那麼如果要取下一個記錄，就需要讀取下一個資料頁
• 概率很低：對於整型欄位索引，一個數據頁（16KB，compact格式）可以存放大概745個值

change buffer

1、當需要更新一個數據頁時，如果資料頁在記憶體中就直接更新

2、如果這個資料頁不在記憶體中，在不影響資料一致性的前提下

• InnoDB會將這些更新操作快取在change buffer
• 不需要從磁碟讀入這個資料頁（隨機讀）
• 在下次查詢需要訪問這個資料頁的時候，將資料頁讀入記憶體
  然後執行change buffer中與這個資料頁有關的操作（merge）

3、change buffer是可以持久化的資料，在記憶體中有拷貝，也會被寫入到磁碟上

4、將更新操作先記錄在channge buffer，減少隨機讀磁碟，提升語句的執行速度

5、另外資料頁讀入記憶體需要佔用buffer pool，使用channge buffer能避免佔用記憶體，提高記憶體利用率

6、change buffer用到是buffer pool裡的記憶體，不能無限增大，控制引數innodb_change_buffer_max_size

# 預設25，最大50
mysql> SHOW VARIABLES LIKE '%innodb_change_buffer_max_size%';
+-------------------------------+-------+
| Variable_name   | Value |
+-------------------------------+-------+
| innodb_change_buffer_max_size | 25 |
+-------------------------------+-------+

merge

1、merge：將change buffer中的操作應用到原資料頁

2、merge的執行過程

• 從磁碟讀入資料頁到記憶體（老版本的資料頁）
• 從change buffer裡找出這個資料頁的change buffer記錄（可能多個）
  然後依次執行，得到新版本的資料頁
• 寫入redolog，包含內容：資料頁的表更+change buffer的變更
  

3、merge執行完後，記憶體中的資料頁和change buffer所對應的磁碟頁都還沒修改，屬於髒頁

• 通過其他機制，髒頁會被重新整理到對應的物理磁碟頁

4、觸發時機

• 訪問這個資料頁
• 系統後臺執行緒定期merge
• 資料庫正常關閉

使用條件

1、對於唯一索引來說，所有的更新操作需要先判斷這個操作是否違反唯一性約束

2、唯一索引的更新無法使用change buffer，只有普通索引可以使用change buffer

• 主鍵也是無法使用change buffer的
• 例如要插入(4,400)，必須先判斷表中是否存在k=4的記錄，這個判斷的前提是將資料頁讀入記憶體
• 既然資料頁已經讀入到了記憶體，直接更新記憶體中的資料頁就好，無需再寫change buffer

使用場景

1、一個數據頁在merge之前，change buffer記錄關於這個資料頁的變更越多，收益越大

2、對於寫多讀少的業務，頁面在寫完後馬上被訪問的概率極低，此時change buffer的使用效果最好

• 例如賬單類、日誌類的系統

3、如果一個業務的更新模式為：寫入之後馬上會做查詢

• 雖然更新操作被記錄到change buffer，但之後馬上查詢，又會從磁碟讀取資料頁，觸發merge過程
• 沒有減少隨機讀，反而增加了維護change buffer的代價

更新過程

插入(4,400)

目標頁在記憶體中

• 對於唯一索引來說，找到3~5之間的位置，判斷沒有衝突，插入這個值
• 對於普通索引來說，找到3~5之間的位置，插入這個值
• 效能差異：微乎其微

目標頁不在記憶體中

1、對於唯一索引來說，需要將資料頁讀入記憶體，判斷沒有衝突，插入這個值

• 磁碟隨機讀，成本很高

對於普通索引來說，將更新操作記錄在change buffer即可

• 減少了磁碟隨機讀，效能提升明顯

索引選擇

1、普通索引與唯一索引，在查詢效能上並沒有太大差異，主要考慮的是更新效能，推薦選擇普通索引

2、建議關閉change buffer的場景

• 如果所有的更新後面，都伴隨著對這個記錄的查詢
• 控制引數innodb_change_buffering

mysql> SHOW VARIABLES LIKE '%innodb_change_buffering%';
+-------------------------+-------+
| Variable_name   | Value |
+-------------------------+-------+
| innodb_change_buffering | all |
+-------------------------+-------+

# Valid Values (>= 5.5.4)
none / inserts / deletes / changes / purges / all

# Valid Values (<= 5.5.3)
none / inserts

# change buffer的前身是insert buffer，只能對insert操作進行優化

change buffer + redolog

更新過程

當前k樹的狀態：找到對應的位置後，k1所在的資料頁Page 1在記憶體中，k2所在的資料頁Page 2不在記憶體中

INSERT INTO t(id,k) VALUES (id1,k1),(id2,k2);

# 記憶體：buffer pool
# redolog：ib_logfileX
# 資料表空間：t.ibd
# 系統表空間：ibdata1

1、Page 1在記憶體中，直接更新記憶體

2、Page 2不在記憶體中，在changer buffer中記錄：add (id2,k2) to Page 2

3、上述兩個動作計入redolog（磁碟順序寫）

4、至此事務完成，執行更新語句的成本很低

• 寫兩次記憶體+一次磁碟

5、由於在事務提交時，會把change buffer的操作記錄也記錄到redolog

• 因此可以在崩潰恢復時，恢復change buffer

虛線為後臺操作，不影響更新操作的響應時間

讀過程

假設：讀語句發生在更新語句後不久，記憶體中的資料都還在，與系統表空間（ibdata1）和redolog（ib_logfileX）無關

SELECT * FROM t WHERE k IN (k1,k2);

1、讀Page 1，直接從記憶體返回（此時Page 1有可能還是髒頁，並未真正落盤）

2、讀Page 2，通過磁碟隨機讀將資料頁讀入記憶體，然後應用change buffer裡面的操作日誌（merge）

• 生成一個正確的版本並返回

提升更新效能

1、redolog：節省隨機寫磁碟的IO消耗（順序寫）

2、change buffer：節省隨機讀磁碟的IO消耗

參考資料

《MySQL實戰45講》

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對我們的支援。