MySQL 儲存引擎簡介

文章目錄

• 3.5.1 Merge儲存引擎：
• 3.5.2 Memory儲存引擎：
• 3.5.3 BDB 儲存引擎：
• 3.5.5 ARCHIVE儲存引擎：
• 3.5.6 BLACKHOLE儲存引擎：
• 3.5.7 CSV儲存引擎：

MySQL  儲存引擎簡介

 

來源：http://simpleframework.net/blog/v/35130.html

 

3．1MySQL 儲存引擎概述

MyISAM 儲存引擎是MySQL 預設的儲存引擎，也是目前MySQL 使用最為廣泛的儲存引擎 之一。他的前身就是我們在MySQL 發展曆程中所提到的ISAM，是ISAM 的升級版本。在MySQL 最開始發行的時候是ISAM 儲存引擎，而且實際上在最初的時候，MySQL 甚至是沒有儲存引 擎這個概念的。MySQL 在架構上面也沒有像現在這樣的sql layer 和storage engine layer 這兩個結構清晰的階層，當時不管是代碼本身還是系統架構，對於開發人員來說都很痛苦 的一件事情。到後來，MySQL 意識到需要更改架構，將前端的商務邏輯和後端資料存放區以 清晰的階層拆分開的同時，對ISAM 做了功能上面的擴充和代碼的重構，這就是MyISAM 儲存引擎的由來。

MySQL 在5.1（不包括）之前的版本中，儲存引擎是需要在MySQL 安裝的時候就必須和 MySQL 一起被編譯並同時被安裝的。也就是說，5.1 之前的版本中，雖然儲存引擎層和sql 層的耦合已經非常少了，基本上完全是通過介面來實現互動，但是這兩層之間仍然是沒辦法 分離的，即使在安裝的時候也是一樣。

但是從MySQL5.1 開始，MySQL AB 對其結構體系做了較大的改造，並引入了一個新的概 念：外掛程式式儲存引擎體繫結構。MySQL AB 在架構改造的時候，讓儲存引擎層和sql 層各自 更為獨立，耦合更小，甚至可以做到線上載入信的儲存引擎，也就是完全可以將一個新的存 儲引擎載入到一個正在啟動並執行MySQL 中，而不影響MySQL 的正常運行。外掛程式式儲存引擎的 架構，為儲存引擎的載入和移出更為靈活方便，也使自行開發儲存體引擎更為方便簡單。在這 一點上面，目前還沒有哪個資料庫管理系統能夠做到。

MySQL 的外掛程式式儲存引擎主要包括MyISAM，Innodb，NDB Cluster，Maria，Falcon， Memory，Archive，Merge，Federated 等，其中最著名而且使用最為廣泛的MyISAM 和Innodb 兩種儲存引擎。MyISAM 是MySQL 最早的ISAM 儲存引擎的升級版本，也是MySQL 預設的儲存 引擎。而Innodb 實際上並不是MySQ 公司的，而是第三方軟體公司Innobase（在2005 年 被Oracle 公司所收購）所開發，其最大的特點是提供了事務控制等特性， 所以使用者也非 常廣泛。

其他的一些儲存引擎相對來說使用情境要稍微少一些，都是應用於某些特定的情境，如 NDB Cluster 雖然也支援事務，但是主要是用於分布式環境，屬於一個share nothing 的分 布式資料庫儲存引擎。Maria 是MySQL 最新開發（還沒有發布最終的GA 版本）的對MyISAM 的升級版儲存引擎，Falcon 是MySQL 公司自行研發的為了替代當前的Innodb 儲存引擎的一 款帶有事務等進階特性的資料庫儲存引擎，目前正在研發階段。Memory 儲存引擎所有資料 和索引均儲存於記憶體中，所以主要是用於一些暫存資料表，或者對效能要求極高，但是允許在西 噢他嗯Crash 的時候遺失資料的特定情境下。Archive 是一個資料經過高比例壓縮存放的 儲存引擎，主要用於存放到期而且很少訪問的曆史資訊，不支援索引。Merge 和Federated 在嚴格意義上來說，並不能算作一個儲存引擎。因為Merge 儲存引擎主要用於將幾個基表 merge 到一起，對外作為一個表來提供服務，基表可以基於其他的幾個儲存引擎。而 Federated 實際上所做的事情，有點類似於Oracle 的dblink，主要用於遠程存取其他MySQL 伺服器上面的資料。

3．2MyISAM 儲存引擎簡介

MyISAM 儲存引擎的表在資料庫中，每一個表都被存放為三個以表名命名的物理檔案。 首先肯定會有任何儲存引擎都不可缺少的存放表結構定義資訊的.frm 檔案，另外還有.MYD 和.MYI 檔案，分別存放了表的資料（.MYD）和索引資料（.MYI）。每個表都有且僅有這樣三 個檔案做為MyISAM 儲存類型的表的儲存，也就是說不管這個表有多少個索引，都是存放在 同一個.MYI 檔案中。

MyISAM 支援以下三種類型的索引：

1、B-Tree 索引

B-Tree 索引，顧名思義，就是所有的索引節點都按照balance tree 的資料結構來 儲存，所有的索引資料節點都在分葉節點。

2、R-Tree 索引

R-Tree 索引的儲存方式和b-tree 索引有一些區別，主要設計用於為儲存空間和多 維資料的欄位做索引，所以目前的MySQL 版本來說，也僅支援geometry 類型的欄位作索引。

3、Full-text 索引

Full-text 索引就是我們長說的全文索引，他的儲存結構也是b-tree。主要是為了 解決在我們需要用like 查詢的低效問題。

MyISAM 上面三種索引類型中，最經常使用的就是B-Tree 索引了，偶爾會使用到Fulltext， 但是R-Tree 索引一般系統中都是很少用到的。另外MyISAM 的B-Tree 索引有一個較 大的限制，那就是參與一個索引的所有欄位的長度之和不能超過1000 位元組。

雖然每一個MyISAM 的表都是存放在一個相同尾碼名的.MYD 檔案中，但是每個檔案的存 放格式實際上可能並不是完全一樣的，因為MyISAM 的資料存放格式是分為靜態（FIXED）固 定長度、動態（DYNAMIC）可變長度以及壓縮（COMPRESSED）這三種格式。當然三種格式中 是否壓縮是完全可以任由我們自己選擇的，可以在建立表的時候通過ROW_FORMAT 來指定 {COMPRESSED | DEFAULT}，也可以通過myisampack 工具來進行壓縮，預設是不壓縮的。而 在非壓縮的情況下，是靜態還是動態，就和我們表中個欄位的定義相關了。只要表中有可變 長度類型的欄位存在，那麼該表就肯定是DYNAMIC 格式的，如果沒有任何可變長度的欄位， 則為FIXED 格式，當然，你也可以通過alter table 命令，強行將一個帶有VARCHAR 類型字 段的DYNAMIC 的錶轉換為FIXED，但是所帶來的結果是原VARCHAR 欄位類型會被自動轉換成 CHAR 類型。相反如果將FIXED 轉換為DYNAMIC，也會將CHAR 類型欄位轉換為VARCHAR 類型， 所以大家手工強行轉換的操作一定要謹慎。

MyISAM 儲存引擎的表是否足夠可靠呢？在MySQL 使用者參考手冊中列出在遇到如下情況 的時候可能會出現表檔案損壞：

1. 當mysqld 正在做寫操作的時候被kill 掉或者其他情況造成異常終止；
2. 主機Crash；
3. 磁碟硬體故障；
4. MyISAM 儲存引擎中的bug？

MyISAM 儲存引擎的某個表檔案出錯之後，僅影響到該表，而不會影響到其他表，更不 會影響到其他的資料庫。如果我們的出據苦正在運行過程中發現某個MyISAM 表出現問題了， 則可以線上通過check table 命令來嘗試校正他，並可以通過repair table 命令來嘗試修 複。在資料庫關閉狀態下，我們也可以通過myisamchk 工具來對資料庫中某個（或某些）表 進行檢測或者修複。不過強烈建議不到萬不得已不要輕易對錶進行修複操作，修複之前盡量 做好可能的備份工作，以免帶來不必要的後果。

另外MyISAM 儲存引擎的表理論上是可以被多個資料庫執行個體同時使用同時操作的，但是 不論是我們都不建議這樣做，而且MySQL 官方的使用者手冊中也有提到，建議盡量不要在多個 mysqld 之間共用MyISAM 隱藏檔。

3．3 Innodb 儲存引擎簡介

在MySQL 中使用最為廣泛的除了MyISAM 之外，就非Innodb 莫屬了。Innodb 做為第三 方公司所開發的儲存引擎，和MySQL 遵守相同的開源License 協議。 Innodb 之所以能如此受寵，主要是在於其功能方面的較多特點：

1、支援事務安裝

Innodb 在功能方面最重要的一點就是對事務安全的支援，這無疑是讓Innodb 成為MySQL 最為流行的儲存引擎之一的一個非常重要原因。而且實現了SQL92 標準所定義的所有四個級 別（READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ 和SERIALIZABLE）。對事務安 全的支援，無疑讓很多之前因為特殊業務要求而不得不放棄使用MySQL 的使用者轉向支援 MySQL，以及之前對資料庫選型持觀望態度的使用者，也大大增加了對MySQL 好感。

2、資料多版本讀取

Innodb 在事務支援的同時，為了保證資料的一致性已經並發時候的效能，通過對undo 資訊，實現了資料的多版本讀取。

3、鎖定機制的改進

Innodb 改變了MyISAM 的鎖機制，實現了行鎖。雖然Innodb 的行鎖機制的實現是通過 索引來完成的，但畢竟在資料庫中99%的SQL 陳述式都是要使用索引來做檢索資料的。所以， 行鎖定機制也無疑為Innodb 在承受高並發壓力的環境下增強了不小的競爭力。

4、實現外鍵

Innodb 實現了外鍵引用這一資料庫的重要特性，使在資料庫端控制部分資料的完整性 成為可能。雖然很多資料庫系統調優專家都建議不要這樣做，但是對於不少使用者來說在資料 庫端加如外鍵控制可能仍然是成本最低的選擇。

除了以上幾個功能上面的亮點之外，Innodb 還有很多其他一些功能特色常常帶給使用 者不小的驚喜，同時也為MySQL 帶來了更多的客戶。

在實體儲存體方賣弄，Innodb 儲存引擎也和MyISAM 不太一樣，雖然也有.frm 檔案來存放 表結構定義相關的中繼資料，但是表資料和索引資料是存放在一起的。至於是每個表單獨存放 還是所有表存放在一起，完全由使用者來決定（通過特定配置），同時還支援符號連結。

Innodb 的物理結構分為兩大部分：

1、資料檔案（表資料和索引資料）

存放資料表中的資料和所有的索引資料，包括主鍵和其他普通索引。在Innodb 中，存 在了資料表空間（tablespace）這樣一個概念，但是他和Oracle 的資料表空間又有較大的不同。首 先，Innodb 的資料表空間分為兩種形式。一種是共用資料表空間，也就是所有表和索引資料被存放 在同一個資料表空間（一個或多個資料檔案）中，通過innodb_data_file_path 來指定，增加數 據檔案需要停機重啟。另外一種是獨享資料表空間，也就是每個表的資料和索引被存放在一個 單獨的.ibd 檔案中。

雖然我們可以自行設定使用共用資料表空間還是獨享資料表空間來存放我們的表，但是共用表空 間都是必須存在的，因為Innodb 的undo 資訊和其他一些中繼資料資訊都是存放在共用資料表空間 裡面的。共用資料表空間的資料檔案是可以設定為固定大小和可自動擴充大小兩種形式的，自動 擴充形式的檔案可以設定檔案的最大大小和每次擴充量。在建立自動擴充的資料檔案的時 候，建議大家最好加上最大尺寸的屬性，一個原因是檔案系統本身是有一定大小限制的（但 是Innodb 並不知道），還有一個原因就是自身維護的方便。另外，Innodb 不僅可以使用文 件系統，還可以使用原始塊裝置，也就是我們常說的裸裝置。

當我們的檔案資料表空間快要用完的時候，我們必須要為其增加資料檔案，當然，只有共用 資料表空間有此操作。共用資料表空間增加資料檔案的操作比較簡單， 只需要在 innodb_data_file_path 參數後面按照標準格式設定好檔案路徑和相關屬性即可，不過這裡 有一點需要注意的，就是Innodb 在建立新資料檔案的時候是不會建立目錄的，如果指定目 錄不存在，則會報錯並無法啟動。另外一個較為令人頭疼的就是Innodb 在給共用資料表空間增 加資料檔案之後，必須要重啟資料庫系統才會生效，如果是使用裸裝置，還需要有兩次重啟。 這也是我一直不太喜歡使用共用資料表空間而選用獨享資料表空間的原因之一。

2、記錄檔

Innodb 的記錄檔和Oracle 的redo 日誌比較類似，同樣可以設定多個日誌組（最少2 個），同樣採用輪循策略來順序的寫入，甚至在老版本中還有和Oracle 一樣的日誌歸檔特性。 如果你的資料庫中有建立了Innodb 的表，那麼千萬別全部刪除innodb 的記錄檔，因為很 可能就會讓你的資料庫crash，無法啟動，或者是遺失資料。

由於Innodb 是事務安全的儲存引擎，所以系統Crash 對他來說並不能造成非常嚴重的 損失，由於有redo 日誌的存在，有checkpoint 機制的保護，Innodb 完全可以通過redo 日 志將資料庫Crash 時刻已經完成但還沒有來得及將資料寫入磁碟的事務恢複，也能夠將所有 部分完成並已經寫入磁碟的未完成交易回復並將資料還原。

Innodb 不僅在功能特性方面和MyISAM 儲存引擎有較大區別，在配置上面也是單獨處理 的。在MySQL 啟動參數檔案設定中，Innodb 的所有參數基本上都帶有首碼“innodb_”，不 論是innodb 資料和日誌相關，還是其他一些效能，事務等等相關的參數都是一樣。和所有 Innodb 相關的系統變數一樣，所有的Innodb 相關的系統狀態值也同樣全部以“Innodb_” 首碼。當然，我們也完全可以僅僅通過一個參數（skip-innodb）來屏蔽MySQL 中的Innodb 儲存引擎，這樣即使我們在安裝編譯的時候將Innodb 儲存引擎安裝進去了，使用者也無法 建立Innodb 的表。

3．4 NDB Cluster 儲存引擎簡介

NDB 儲存引擎也叫NDB Cluster 儲存引擎，主要用於MySQL Cluster 分布式叢集環境， Cluster 是MySQL 從5.0 版本才開始提供的新功能。這部分我們可能並不僅僅只是介紹NDB 儲存引擎，因為離開了MySQL CLuster 整個環境，NDB 儲存引擎也將失去太多意義。所以 這一節主要是介紹一下MySQL Cluster 的相關內容。

簡單的說，Mysql Cluster 實際上就是在無共用存放裝置的情況下實現的一種記憶體資料 庫Cluster 環境，其主要是通過NDB Cluster（簡稱NDB）儲存引擎來實現的。 一般來說，一個Mysql Cluster 的環境主要由以下三部分組成：

a) 負責管理各個節點的Manage 節點主機：

管理節點負責整個Cluster 叢集中各個節點的管理工作，包括叢集的配置，啟動關閉 各節點，以及實施資料的備份恢複等。管理節點會擷取整個Cluster 環境中各節點的狀態和 錯誤資訊，並且將各Cluster 叢集中各個節點的資訊反饋給整個叢集中其他的所有節點。由 於管理節點上儲存在整個Cluster 環境的配置，同時擔任了叢集中各節點的基本溝通工作， 所以他必須是最先被啟動的節點。

b) SQL 層的SQL 伺服器節點（後面簡稱為SQL 節點），也就是我們常說的Mysql Server： 主要負責實現一個資料庫在儲存層之上的所有事情，比如串連管理，query 最佳化和響 應，cache 管理等等，只有儲存層的工作交給了NDB 資料節點去處理了。也就是說，在純粹 的Mysql Cluster 環境中的SQL 節點，可以被認為是一個不需要提供任何儲存引擎的Mysql 伺服器，因為他的儲存引擎有Cluster 環境中的NDB 節點來擔任。所以，SQL 層各Mysql 服 務器的啟動與普通的Mysql 啟動有一定的區別，必須要添加ndbcluster 項，可以添加在 my.cnf 設定檔中，也可以通過啟動命令列來指定。

c) Storage 層的NDB 資料節點，也就是上面說的NDB Cluster：

NDB 是一個記憶體式儲存引擎也就是說，他會將所有的資料和索引資料都load 到記憶體中， 但也會將資料持久化到存放裝置上。不過，最新版本，已經支援使用者自己選擇資料可以不全 部Load 到記憶體中了，這對於有些資料量太大或者基於成本考慮而沒有足夠記憶體空間來存放 所有資料的使用者來說的確是一個大好訊息。

NDB 節點主要是實現底層資料存放區的功能，儲存Cluster 的資料。每一個NDB 節點儲存 完整資料的一部分（或者一份完整的資料，視節點數目和配置而定），在MySQL CLuster 裡 面叫做一個fragment。而每一個fragment，正常情況來講都會在其他的主機上面有一份（或 者多分）完全相同的鏡像存在。這些都是通過配置來完成的，所以只要配置得當，Mysql Cluster 在儲存層不會出現單點的問題。一般來說，NDB 節點被組織成一個一個的NDB Group， 一個NDB Group 實際上就是一組存有完全相同的物理資料的NDB 節點群。

上面提到了NDB 各個節點對資料的組織，可能每個節點都存有全部的資料也可能只儲存 一部分資料，主要是受節點數目和參數來控制的。首先在Mysql Cluster 主設定檔（在管 理節點上面，一般為config.ini）中，有一個非常重要的參數叫NoOfReplicas，這個參數 指定了每一份資料被冗餘儲存在不同節點上面的份數，該參數一般至少應該被設定成2，也 只需要設定成2 就可以了。因為正常來說，兩個互為冗餘的節點同時出現故障的機率還是非 常小的，當然如果機器和記憶體足夠多的話，也可以繼續增大。一個節點上面是儲存所有的數 據還是一部分資料，還受到儲存節點數目的限制。NDB 儲存引擎首先保證NoOfReplicas 參 數配置的要求對資料冗餘，來使用儲存節點，然後再根據節點數目將資料分段來繼續使用多 餘的NDB 節點，分段的數目為節點總數除以NoOfReplicas 所得。

MySQL Cluster 本身所包含的內容非常之多，出於篇幅考慮，這裡暫時不做很深入的介 紹，在本書的架構設計部分的高可用性設計一章中將會有更為詳細的介紹與實施細節，大家 也可以通過MySQL 官方文檔來進一步瞭解部分細節。

3．5 其他儲存引擎介紹3.5.1 Merge儲存引擎：

MERGE 儲存引擎，在MySQL 使用者手冊中也提到了，也被大家認識為MRG_MyISAM 引擎。 Why？因為MERGE 儲存引擎可以簡單的理解為其功能就是實現了對結構相同的MyISAM 表，通 過一些特殊的封裝對外提供一個單一的訪問入口，以達到減小應用的複雜度的目的。要建立 MERGE 表，不僅僅基表的結構要完全一致，包括欄位的順序，基表的索引也必須完全一致。 MERGE 表本身並不儲存資料，僅僅只是為多個基表提供一個同意的儲存入口。所以在創 建MERGE 表的時候，MySQL 只會產生兩個較小的檔案，一個是.frm 的結構定義檔案，還有一 個.MRG 檔案，用於存放參與MERGE 的表的名稱（包括所屬資料庫schema）。之所以需要有所 屬資料庫的schema，是因為MERGE 表不僅可以實現將Merge 同一個資料庫中的表，還可以 Merge 不同資料庫中的表，只要是許可權允許，並且在同一個mysqld 下面，就可以進行Merge。 MERGE 表在被建立之後，仍然可以通過相關命令來更改底層的基表。

MERGE 表不僅可以提供讀取服務，也可以提供寫入服務。要讓MERGE 表提供可INSERT 服務，必須在在表被建立的時候就指明INSERT 資料要被寫入哪一個基表，可以通過 insert_method 參數來控制。如果沒有指定該參數，任何嘗試往MERGE 表中INSERT 資料的 操作，都會出錯。此外，無法通過MERGE 表直接使用基表上面的全文索引，要使用全文索引， 必須通過基表本身的存取才能實現。

3.5.2 Memory儲存引擎：

Memory 儲存引擎，通過名字就很容易讓人知道，他是一個將資料存放區在記憶體中的儲存 引擎。Memory 儲存引擎不會將任何資料存放到磁碟上，僅僅存放了一個表結構相關資訊 的.frm 檔案在磁碟上面。所以一旦MySQL Crash 或者主機Crash 之後，Memory 的表就只剩 下一個結構了。Memory 表支援索引，並且同時支援Hash 和B－Tree 兩種格式的索引。由於 是存放在記憶體中，所以Memory 都是按照定長的空間來儲存資料的，而且不支援BLOB 和TEXT 類型的欄位。Memory 儲存引擎實現頁級鎖定。

既然所有資料都存放在記憶體中，那麼他對記憶體的消耗量是可想而知的。在MySQL 的使用者 手冊上面有這樣一個公式來計算Memory 表實際需要消耗的記憶體大小：

SUM_OVER_ALL_BTREE_KEYS(max_length_of_key + sizeof(char*) * 4) + SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2) + ALIGN(length_of_row+1, sizeof(char*))

3.5.3 BDB 儲存引擎：

BDB 儲存引擎全稱為BerkeleyDB 儲存引擎，和Innodb 一樣，也不是MySQL 自己開發實 現的一個儲存引擎，而是由Sleepycat Software 所提供，當然，也是開源儲存引擎，同樣 支援事務安全。

BDB 儲存引擎的資料存放也是每個表兩個物理檔案，一個.frm 和一個.db 的檔案，資料 和索引資訊都是存放在.db 檔案中。此外，BDB 為了實現事務安全，也有自己的redo 日誌， 和Innodb 一樣，也可以通過參數指定記錄檔存放的位置。在鎖定機制方面，BDB 和Memory 儲存引擎一樣，實現頁級鎖定。

由於BDB 儲存引擎實現了事務安全，那麼他肯定也需要有自己的check point 機制。BDB 在每次啟動的時候，都會做一次check point，並且將之前的所有redo 日誌清空。在運行 過程中，我們也可以通過執行flush logs 來手工對BDB 進行check point 操作。

3.5.4 FEDERATED儲存引擎：

FEDERATED 儲存引擎所實現的功能，和Oracle 的DBLINK 基本相似，主要用來提供對遠 程MySQL 伺服器上面的資料的訪問借口。如果我們使用源碼編譯來安裝MySQL，那麼必須手 工指定啟用

FEDERATED 儲存引擎才行，因為MySQL 預設是不起用該儲存引擎的。 當我們建立一個FEDERATED 表的時候，僅僅在本地建立了一個表的結構定義資訊的檔案 而已，所有資料均即時取自遠端MySQL 伺服器上面的資料庫。

當我們通過SQL 操作FEDERATED 表的時候，實現過程基本如下：

1. SQL 調用被本地發布
2. MySQL 處理器API（資料以處理器格式）
3. MySQL 用戶端API（資料被轉換成SQL 調用）
4. 遠端資料庫-> MySQL 用戶端API
5. 轉換結果包（如果有的話）到處理器格式
6. 處理器API -> 結果行或受行影響的對本地的計數

3.5.5 ARCHIVE儲存引擎：

ARCHIVE 儲存引擎主要用於通過較小的儲存空間來存放到期的很少訪問的曆史資料。 ARCHIVE 表不支援索引，通過一個.frm 的結構定義檔案，一個.ARZ 的資料壓縮檔還有一 個.ARM 的meta 資訊檔。由於其所存放的資料的特殊性，ARCHIVE 表不支援刪除，修改操 作，僅支援插入和查詢操作。鎖定機製為行級鎖定。

3.5.6 BLACKHOLE儲存引擎：

BLACKHOLE 儲存引擎是一個非常有意思的儲存引擎，功能恰如其名，就是一個“黑洞”。 就像我們unix 系統下面的“/dev/null”裝置一樣，不管我們寫入任何資訊，都是有去無回。 那麼BLACKHOLE儲存引擎對我們有什麼用呢？在我最初接觸MySQL 的時候我也有過同樣的疑 問，不知道MySQL 提供這樣一個儲存引擎給我們的用意為何？但是後來在又一次資料的遷移 過程中，正是BLACKHOLE 給我帶來了非常大的功效。在那次資料移轉過程中，由於資料需要 經過一個中轉的MySQL 伺服器做一些相關的轉換操作，然後再通過複製移植到新的伺服器上 面。可當時我沒有足夠的空間來支援這個代理服務器的運作。這時候就顯示出BLACKHOLE 的功效了，他不會記錄下任何資料，但是會在binlog 中記錄下所有的sql。而這些sql 最 終都是會被複製所利用，並實施到最終的slave 端。

MySQL 的使用者手冊上面還介紹了BLACKHOLE 儲存引擎其他幾個用途如下：

1. SQL 檔案文法的驗證。
2. 來自二進位日誌記錄的開銷測量，通過比較允許二進位日誌功能的BLACKHOLE 的效能與禁止二進位日誌功能的BLACKHOLE 的效能。
3. 因為BLACKHOLE 本質上是一個“no-op” 儲存引擎，它可能被用來尋找與儲存引擎自身不相關的效能瓶頸。

3.5.7 CSV儲存引擎：

CSV 儲存引擎實際上操作的就是一個標準的CSV 檔案，他不支援索引。起主要用途就是 大家有些時候可能會需要通過資料庫中的資料匯出成一份報表檔案，而CSV 檔案是很多軟體 都支援的一種較為標準的格式，所以我們可以通過先在資料庫中建立一張CVS 表，然後將生 成的報表資訊插入到該表，即可得到一份CSV 報表檔案了。

3．6 小結

多儲存引擎是MySQL 有別於其他資料庫管理軟體的最大特色，不同的儲存引擎有不同 的特點，可以應對不同的應用情境，這讓我們在實際的應用中可以根據不同的應用特點來選 擇最有利的儲存引擎，給了我們足夠的靈活性。通過這一章對MySQL 各個儲存引擎的初步 瞭解，我想各位讀者朋友應該已經對MySQL 的主要儲存引擎有了一定的認識，在後續的章 節中對於一些常用的儲存引擎還會有更為深入的介紹。