MySQL 里還有什么其他成員呢？

對于 MySQL，要記住、或者要放在你隨時可以找到的地方的兩張圖，一張是 MySQL 架構圖，另一張則是 InnoDB 架構圖：

遇到問題，或者學習到新知識點時，就往里套，想一想，這是對應這兩張圖的哪個模塊、是屬于具體哪個成員的能力。

這其中，第一張圖的最底下的存儲引擎層(Storage Engines)，它決定了 MySQL 會怎樣存儲數據，怎樣讀取和寫入數據，也在很大程度上決定了 MySQL 的讀寫性能和數據可靠性。

對于這么重要的一層能力，MySQL 提供了極強的擴展性，你可以定義自己要使用什么樣的存儲引擎：InnoDB、MyISAM、MEMORY、CSV，甚至可以自己開發一個存儲引擎然后使用它。

我一直覺得 MySQL 的設計，是教科書式的，高內聚松耦合，邊界明確，職責清晰。學習 MySQL，學的不只是如何更好的使用 MySQL，更是學習如何更好的進行系統設計。

通常我們說 Mysql 高性能高可靠，都是指基于 InnoDB 存儲引擎的 Mysql，所以，這一講，先讓我們來看看，除了 redo log，InnoDB 里還有哪些成員，他們都有什么能力，承擔了什么樣的角色，他們之間又是怎么配合的？

InnoDB 內存架構

從上面第二張圖可以看到，InnoDB 主要分為兩大塊：

InnoDB In-Memory Structures

InnoDB On-Disk Structures

內存和磁盤，讓我們先從內存開始。

1、Buffer Pool

The buffer pool is an area in main memory where InnoDB caches table and index data as it is accessed.

正如之前提到的，MySQL 不會直接去修改磁盤的數據，因為這樣做太慢了，MySQL 會先改內存，然后記錄 redo log，等有空了再刷磁盤，如果內存里沒有數據，就去磁盤 load。

而這些數據存放的地方，就是 Buffer Pool。

我們平時開發時，會用 redis 來做緩存，緩解數據庫壓力，其實 MySQL 自己也做了一層類似緩存的東西。

MySQL 是以「頁」(page)為單位從磁盤讀取數據的，Buffer Pool 里的數據也是如此，實際上，Buffer Pool 是a linked list of pages，一個以頁為元素的鏈表。

為什么是鏈表？因為和緩存一樣，它也需要一套淘汰算法來管理數據。

Buffer Pool 采用基于 LRU(least recently used) 的算法來管理內存：

關于 Buffer Pool 的更多知識，諸如如何配置大小、如何監控等等：Buffer Pool

2、Change Buffer

上面提到過，如果內存里沒有對應「頁」的數據，MySQL 就會去把數據從磁盤里 load 出來，如果每次需要的「頁」都不同，或者不是相鄰的「頁」，那么每次 MySQL 都要去 load，這樣就很慢了。

于是如果 MySQL 發現你要修改的頁，不在內存里，就把你要對頁的修改，先記到一個叫 Change Buffer 的地方，同時記錄 redo log，然后再慢慢把數據 load 到內存，load 過來后，再把 Change Buffer 里記錄的修改，應用到內存(Buffer Pool)中，這個動作叫做?merge；而把內存數據刷到磁盤的動作，叫?purge：

merge：Change Buffer -> Buffer Pool

purge：Buffer Pool -> Disk

The change buffer is a special data structure that caches changes to?secondary index?pages when those pages are not in the?buffer pool. The buffered changes, which may result from INSERT, UPDATE, or DELETE operations (DML), are?merged?later when the pages are loaded into the buffer pool by other read operations.

上面是 MySQL 官網對 Change Buffer 的定義，仔細看的話，你會發現里面提到：Change Buffer 只在操作「二級索引」(secondary index)時才使用，原因是「聚簇索引」(clustered indexes)必須是「唯一」的，也就意味著每次插入、更新，都需要檢查是否已經有相同的字段存在，也就沒有必要使用 Change Buffer 了；另外，「聚簇索引」操作的隨機性比較小，通常在相鄰的「頁」進行操作，比如使用了自增主鍵的「聚簇索引」，那么 insert 時就是遞增、有序的，不像「二級索引」，訪問非常隨機。

如果想深入理解 Change Buffer 的原理，除了 MySQL 官網的介紹：Change Buffer，還可以閱讀下《MySQL技術內幕》的「2.6.1 - 插入緩沖」章節，里面會從 Change Buffer 的前身 —— Insert Buffer 開始講起，很透徹。

3、Adaptive Hash Index

MySQL 索引，不管是在磁盤里，還是被 load 到內存后，都是 B+ 樹，B+ 樹的查找次數取決于樹的深度。你看，數據都已經放到內存了，還不能“一下子”就找到它，還要“幾下子”，這空間犧牲的是不是不太值得？

尤其是那些頻繁被訪問的數據，每次過來都要走 B+ 樹來查詢，這時就會想到，我用一個指針把數據的位置記錄下來不就好了？

這就是「自適應哈希索引」(Adaptive Hash Index)。自適應，顧名思義，MySQL 會自動評估使用自適應索引是否值得，如果觀察到建立哈希索引可以提升速度，則建立。

4、Log Buffer

The log buffer is the memory area that holds data to be written to the log files on disk.

從上面架構圖可以看到，Log Buffer 里的 redo log，會被刷到磁盤里：

Operating System Cache

在內存和磁盤之間，你看到 MySQL 畫了一層叫做 Operating System Cache 的東西，其實這個不屬于 InnoDB 的能力，而是操作系統為了提升性能，在磁盤前面加的一層高速緩存，這里不展開細講，感興趣的同學可以參考下維基百科：Page Cache

InnoDB 磁盤架構

磁盤里有什么呢？除了表結構定義和索引，還有一些為了高性能和高可靠而設計的角色，比如 redo log、undo log、Change Buffer，以及 Doublewrite Buffer 等等.

有同學會問，那表的數據呢？其實只要理解了 InnoDB 里的所有表數據，都以索引(聚簇索引+二級索引)的形式存儲起來，就知道索引已經包含了表數據。

1、表空間(Tablespaces)

從架構圖可以看到，Tablespaces 分為五種：

The System Tablespace

File-Per-Table Tablespaces

General Tablespace

Undo Tablespaces

Temporary Tablespaces

其中，我們平時創建的表的數據，可以存放到 The System Tablespace 、File-Per-Table Tablespaces、General Tablespace 三者中的任意一個地方，具體取決于你的配置和創建表時的 sql 語句。

這里同樣不展開，如何選擇不同的表空間存儲數據？不同表空間各自的優勢劣勢等等，傳送門：Tablespaces

2、Doublewrite Buffer

如果說 Change Buffer 是提升性能，那么 Doublewrite Buffer 就是保證數據頁的可靠性。

怎么理解呢？

前面提到過，MySQL 以「頁」為讀取和寫入單位，一個「頁」里面有多行數據，寫入數據時，MySQL 會先寫內存中的頁，然后再刷新到磁盤中的頁。

這時問題來了，假設在某一次從內存刷新到磁盤的過程中，一個「頁」刷了一半，突然操作系統或者 MySQL 進程奔潰了，這時候，內存里的頁數據被清除了，而磁盤里的頁數據，刷了一半，處于一個中間狀態，不尷不尬，可以說是一個「不完整」，甚至是「壞掉的」的頁。

有同學說，不是有 Redo Log 么？其實這個時候 Redo Log 也已經無力回天，Redo Log 是要在磁盤中的頁數據是正常的、沒有損壞的情況下，才能把磁盤里頁數據 load 到內存，然后應用 Redo Log。而如果磁盤中的頁數據已經損壞，是無法應用 Redo Log 的。

所以，MySQL 在刷數據到磁盤之前，要先把數據寫到另外一個地方，也就是 Doublewrite Buffer，寫完后，再開始寫磁盤。Doublewrite Buffer 可以理解為是一個備份(recovery)，萬一真的發生 crash，就可以利用 Doublewrite Buffer 來修復磁盤里的數據。

留個問題，有了 Doublewrite Buffer 后，不就意味著 MySQL 要寫兩次磁盤？性能豈不是很差？

未完待續

讓我們再來回顧一下這張圖：

這篇文章，順著這張圖，給大家介紹了 InnoDB 里的每一個成員、成員各自扮演的角色、提供的能力。

當然，這張圖里能表達的信息是有限的，我習慣稱這種圖為「架構圖」，或者「模塊圖」。

用 DDD 的話來講，這張圖可以告訴你，MySQL 里有哪些「域」(子域、核心域、通用域、支撐域)，配合文字介紹，可以知道這些「域」之間都有什么樣的能力、行為，知道「域」之間一些簡單的交互。

然而，這張圖并沒有告訴你具體某個業務中，這些成員之間要如何配合，來提供一個服務，或者說，如果你的技術方案里只有這張圖，那你進入開發階段后，最多最多，只能新建幾個微服務應用，新建幾個類和對象，而寫不出這些個微服務、class 之間如何協作起來提供一個服務的代碼。

總結

以上是生活随笔為你收集整理的mysql+如何开发存储引擎_干货！MySQL 的 InnoDB 存储引擎是怎么设计的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。