2.1 MySQL存儲引擎概述

上個業(yè)余的圖：

MyISAM 存儲引擎是 MySQL 默認的存儲引擎，也是目前 MySQL 使用最為廣泛的存儲引擎之一。他的前身就是我們在 MySQL 發(fā)展歷程中所提到的 ISAM，是 ISAM 的升級版本。在 MySQL最開始發(fā)行的時候是 ISAM 存儲引擎，而且實際上在最初的時候，MySQL 甚至是沒有存儲引擎這個概念的。MySQL在架構(gòu)上面也沒有像現(xiàn)在這樣的sql layer和storage engine layer這兩個結(jié)構(gòu)清晰的層次結(jié)構(gòu)，當時不管是代碼本身還是系統(tǒng)架構(gòu)，對于開發(fā)者來說都很痛苦的一件事情。
5.1 之前的 版本中，雖然存儲引擎層和 sql層的耦合已經(jīng)非常少了，基本上完全是通過接口來實現(xiàn)交互，但是這兩層之間仍然是沒辦法分離的，即使在安裝的時候也是一樣。

MySQL5.1 開始，MySQL AB 對其結(jié)構(gòu)體系做了較大的改造，并引入了一個新的概念：插件式存儲引擎體系結(jié)構(gòu)。MySQL AB 在架構(gòu)改造的時候，讓存儲引擎層和 sql 層各自更為獨立，耦合更小，甚至可以做到在線加載信的存儲引擎，也就是完全可以將一個新的存儲引擎加載到一個正在 運行的 MySQL 中，而不影響 MySQL 的正常運行。插件式存儲引擎的架構(gòu)，為存儲引擎的加載和移出更為靈活方便，也使自行開發(fā)存儲引擎更為方便簡單。在 這
一點上面，目前還沒有哪個數(shù)據(jù)庫管理系統(tǒng)能夠做到。MySQL 的插件式存儲引擎主要包括 MyISAM，Innodb，NDB Cluster，Maria，Falcon，Memory，Archive，Merge，Federated 等，**其中最著名而且使用最為廣泛的 MyISAM 和 Innodb兩種存儲引擎。**MyISAM 是 MySQL 最早的 ISAM 存儲引擎的升級版本，也是 MySQL 默認的存儲
引擎。而 Innodb 實 際上并不是 MySQ 公司的，而是第三方軟件公司 Innobase（在 2005 年被 Oracle 公司所收購）所開發(fā)，其最大的特點是提供了事務(wù)控制等特性， 所以使用者也非常廣泛。

2.2 MySQL存儲引擎介紹

MyISAM 存儲引擎簡介

MyISAM 存儲引擎的表在數(shù)據(jù)庫中，每一個表都被存放為三個以表名命名的物理文件。首先肯定會有任何存儲引擎都不可缺少的存放表結(jié)構(gòu)定義信息的.frm 文件，另外還有.MYD和.MYI 文件，分別存放了表的數(shù)據(jù)（.MYD）和索引數(shù)據(jù)（.MYI）。每個表都有且僅有這樣三個文件做為 MyISAM 存儲類型的表的存儲，也就是說不管這個表有多少個索引，都是存放在同一個.MYI 文件中。

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

1、B-Tree 索引

B-Tree 索引，顧名思義，就是所有的索引節(jié)點都按照 balance tree 的數(shù)據(jù)結(jié)構(gòu)來存儲，所有的索引數(shù)據(jù)節(jié)點都在葉節(jié)點。

2、R-Tree 索引

R-Tree 索引的存儲方式和 b-tree 索引有一些區(qū)別，主要設(shè)計用于為存儲空間和多維數(shù)據(jù)的字段做索引，所以目前的 MySQL 版本來說，也僅支持 geometry 類型的字段作索引。

3、Full-text 索引

Full-text 索引就是我們長說的全文索引，他的存儲結(jié)構(gòu)也是 b-tree。主要是為了解決在我們需要用 like 查詢的低效問題。
MyISAM 上面三種索引類型中，最經(jīng)常使用的就是 B-Tree 索引了，偶爾會使用到 Fulltext，但是 R-Tree 索引一般系統(tǒng)中都是很少用到的。另外 MyISAM 的 B-Tree 索引有一個較大的限制，那就是參與一個索引的所有字段的長度之和不能超過 1000 字節(jié)。

雖然每一個 MyISAM 的表都是存放在一個相同后綴名的.MYD 文件中，但是每個文件的存放格式實際上可能并不是完全一樣的，因為 MyISAM 的數(shù)據(jù)存放格式是分為靜態(tài)（FIXED）固定長度、動態(tài)（DYNAMIC）可變長度以及壓縮（COMPRESSED）這三種格式。當然三種格式中是否壓縮是完全可以任由我們自己選擇的，可以在創(chuàng)建表的時候通過 ROW_FORMAT 來指定{COMPRESSED | DEFAULT}，也可以通過 myisampack 工具來進行壓縮，默認是不壓縮的。而在非壓縮的情況下，是靜態(tài)還是動態(tài)，就和我們表中個字段的定義相關(guān)了。只要表中有可變長度類型的字段存在，那么該表就肯定是 DYNAMIC 格式的，如果沒有任何可變長度的字段，則為 FIXED 格式，當然，你也可以通過 alter table 命令，強行將一個帶有 VARCHAR 類型字段的 DYNAMIC 的表轉(zhuǎn)換為 FIXED，但是所帶來的結(jié)果是原 VARCHAR 字段類型會被自動轉(zhuǎn)換成CHAR 類型。相反如果將 FIXED 轉(zhuǎn)換為 DYNAMIC，也會將 CHAR 類型字段轉(zhuǎn)換為 VARCHAR 類型，
所以大家手工強行轉(zhuǎn)換的操作一定要謹慎。

MyISAM 存儲引擎的表是否足夠可靠呢？在 MySQL 用戶參考手冊中列出在遇到如下情況的時候可能會出現(xiàn)表文件損壞：

1、當 mysqld 正在做寫操作的時候被 kill 掉或者其他情況造成異常終止；

2、主機 Crash；

3、磁盤硬件故障；

4、MyISAM 存儲引擎中的 bug？

MyISAM 存儲引擎的某個表文件出錯之后，僅影響到該表，而不會影響到其他表，更不會影響到其他的數(shù)據(jù)庫。如果我們的出據(jù)苦正在運行過程中發(fā)現(xiàn)某個 MyISAM 表出現(xiàn)問題了，則可以在線通過 check table 命令來嘗試校驗他，并可以通過 repair table 命令來嘗試修復(fù)。在數(shù)據(jù)庫關(guān)閉狀態(tài)下，我們也可以通過 myisamchk 工具來對數(shù)據(jù)庫中某個（或某些）表進行檢測或者修復(fù)。不過強烈建議不到萬不得已不要輕易對表進行修復(fù)操作，修復(fù)之前盡量做好可能的備份工作，以免帶來不必要的后果。另外 MyISAM 存儲引擎的表理論上是可以被多個數(shù)據(jù)庫實例同時使用同時操作的，但是不論是我們都不建議這樣做，而且 MySQL 官方的用戶手冊中也有提到，建議盡量不要在多個mysqld 之間共享 MyISAM 存儲文件。

Innodb 存儲引擎簡介

在 MySQL 中使用最為廣泛的除了 MyISAM 之外，就非 Innodb 莫屬了。Innodb 做為第三方公司所開發(fā)的存儲引擎，和 MySQL 遵守相同的開源 License 協(xié)議。Innodb 之所以能如此受寵，主要是在于其功能方面的較多特點：
1、支持事務(wù)安裝
Innodb在功能方面最重要的一點就是對事務(wù)安全的支持，這無疑是讓Innodb成為MySQL最為流行的存儲引擎之一的一個非常重要原因。而且實現(xiàn)了 SQL92 標準所定義的所有四個級別（READ UNCOMMITTED，READ COMMITTED，REPEATABLE READ, SERIALIZABLE）。對事務(wù)安全的支持，無疑讓很多之前因為特殊業(yè)務(wù)要求而不得不放棄使用 MySQL 的用戶轉(zhuǎn)向支持MySQL，以及之前對數(shù)據(jù)庫選型持觀望態(tài)度的用戶，也大大增加了對 MySQL 好感。
2、數(shù)據(jù)多版本讀取
Innodb 在事務(wù)支持的同時，為了保證數(shù)據(jù)的一致性已經(jīng)并發(fā)時候的性能，通過對 undo
信息，實現(xiàn)了數(shù)據(jù)的多版本讀取。
3、鎖定機制的改進
Innodb 改變了 MyISAM 的鎖機制，實現(xiàn)了行鎖。雖然 Innodb 的行鎖機制的實現(xiàn)是通過
索引來完成的，但畢竟在數(shù)據(jù)庫中 99%的 SQL 語句都是要使用索引來做檢索數(shù)據(jù)的。所以，
行鎖定機制也無疑為 Innodb 在承受高并發(fā)壓力的環(huán)境下增強了不小的競爭力。
4、實現(xiàn)外鍵
Innodb 實現(xiàn)了外鍵引用這一數(shù)據(jù)庫的重要特性，使在數(shù)據(jù)庫端控制部分數(shù)據(jù)的完整性成為可能。雖然很多數(shù)據(jù)庫系統(tǒng)調(diào)優(yōu)專家都建議不要這樣做，但是對于不少用戶來說在數(shù)據(jù)庫端加如外鍵控制可能仍然是成本最低的選擇。
除了以上幾個功能上面的亮點之外，Innodb 還有很多其他一些功能特色常常帶給使用者不小的驚喜，同時也為 MySQL 帶來了更多的客戶。
在物理存儲方賣弄，Innodb 存儲引擎也和 MyISAM 不太一樣，雖然也有.frm 文件來存放表結(jié)構(gòu)定義相關(guān)的元數(shù)據(jù)，但是表數(shù)據(jù)和索引數(shù)據(jù)是存放在一起的。至于是每個表單獨存放還是所有表存放在一起，完全由用戶來決定（通過特定配置），同時還支持符號鏈接。

Innodb 的物理結(jié)構(gòu)分為兩大部分：

1、數(shù)據(jù)文件（表數(shù)據(jù)和索引數(shù)據(jù)）

存放數(shù)據(jù)表中的數(shù)據(jù)和所有的索引數(shù)據(jù)，包括主鍵和其他普通索引。在 Innodb 中，存在了表空間（tablespace）這樣一個概念，但是他和 Oracle 的表空間又有較大的不同。首先，Innodb 的表空間分為兩種形式。一種是共享表空間，也就是所有表和索引數(shù)據(jù)被存放在同一個表空間（一個或多個數(shù)據(jù)文件）中，通過 innodb_data_file_path 來指定，增加數(shù)據(jù)文件需要停機重啟。 另外一種是獨享表空間，也就是每個表的數(shù)據(jù)和索引被存放在一個單獨的.ibd 文件中。
雖然我們可以自行設(shè)定使用共享表空間還是獨享表空間來存放我們的表，但是共享表空間都是必須存在的，因為 Innodb 的 undo 信息和其他一些元數(shù)據(jù)信息都是存放在共享表空間里面的。共享表空間的數(shù)據(jù)文件是可以設(shè)置為固定大小和可自動擴展大小兩種形式的，自動擴展形式的文件可以設(shè)置文件的最大大小和每次擴展量。在創(chuàng)建自動擴展的數(shù)據(jù)文件的時候，建議大家最好加上最大尺寸的屬性，一個原因是文件系統(tǒng)本身是有一定大小限制的（但是 Innodb 并不知道），還有一個原因就是自身維護的方便。另外，Innodb 不僅可以使用文
件系統(tǒng)，還可以使用原始塊設(shè)備，也就是我們常說的裸設(shè)備。當我們的文件表空間快要用完的時候，我們必須要為其增加數(shù)據(jù)文件，當然，只有共享表 空 間 有 此 操 作 。 共 享 表 空 間 增 加 數(shù) 據(jù) 文 件 的 操 作 比 較 簡 單 ， 只 需 要 在innodb_data_file_path 參數(shù)后面按照標準格式設(shè)置好文件路徑和相關(guān)屬性即可，不過這里有一點需要注意的，就是 Innodb 在創(chuàng)建新數(shù)據(jù)文件的時候是不會創(chuàng)建目錄的，如果指定目錄不存在，則會報錯并無法啟動。另外一個較為令人頭疼的就是 Innodb 在給共享表空間增加數(shù)據(jù)文件之后，必須要重啟數(shù)據(jù)庫系統(tǒng)才能生效，如果是使用裸設(shè)備，還需要有兩次重啟 。這也是我一直不太喜歡使用共享表空間而選用獨享表空間的原因之一。

2、日志文件

Innodb 的日志文件和 Oracle 的 redo 日志比較類似，同樣可以設(shè)置多個日志組（最少 2個），同樣采用輪循策略來順序的寫入，甚至在老版本中還有和 Oracle 一樣的日志歸檔特性 。如果你的數(shù)據(jù)庫中有創(chuàng)建了 Innodb 的表，那么千萬別全部刪除 innodb 的日志文件，因為很可能就會讓你的數(shù)據(jù)庫 crash，無法啟動，或者是丟失數(shù)據(jù)。由于 Innodb 是事務(wù)安全的存儲引擎，所以系統(tǒng) Crash 對他來說并不能造成非常嚴重的損失，由于有 redo 日志的存在，有 checkpoint 機制的保護，Innodb 完全可以通過 redo 日志將數(shù)據(jù)庫 Crash 時刻已經(jīng)完成但還沒有來得及將數(shù)據(jù)寫入磁盤的事務(wù)恢復(fù)，也能夠?qū)⑺胁糠滞瓿刹⒁呀?jīng)寫入磁盤的未完成事務(wù)回滾并將數(shù)據(jù)還原。

Innodb 不僅在功能特性方面和 MyISAM 存儲引擎有較大區(qū)別，在配置上面也是單獨處理的。在 MySQL 啟動參數(shù)文件設(shè)置中，Innodb 的所有參數(shù)基本上都帶有前綴“innodb_”，不論是 innodb 數(shù)據(jù)和日志相關(guān)，還是其他一些性能，事務(wù)等等相關(guān)的參數(shù)都是一樣。和所有Innodb 相關(guān)的系統(tǒng)變量一樣，所有的 Innodb 相關(guān)的系統(tǒng)狀態(tài)值也同樣全部以“Innodb_”前綴。當然，我們也完全可以僅僅通過一個參數(shù)（skip-innodb）來屏蔽 MySQL 中的 Innodb存儲引擎，這樣即使我們在安裝編譯的時候?qū)?Innodb 存儲引擎安裝進去了，使用者也無法創(chuàng)建 Innodb 的表。

NDB Cluster 存儲引擎簡介

NDB 存儲引擎也叫 NDB Cluster 存儲引擎，主要用于 MySQL Cluster 分布式集群環(huán)境，Cluster 是 MySQL 從 5.0 版本才開始提供的新功能。這部分我們可能并不僅僅只是介紹 NDB存儲引擎，因為離開了 MySQL CLuster 整個環(huán)境，NDB 存儲引擎也將失去太多意義。 簡單的說，Mysql Cluster 實際上就是在無共享存儲設(shè)備的情況下實現(xiàn)的一種內(nèi)存數(shù)據(jù)庫 Cluster 環(huán)境，其主要是通過 NDB Cluster（簡稱 NDB）存儲引擎來實現(xiàn)的。

一般來說，一個 Mysql Cluster 的環(huán)境主要由以下三部分組成：
a) 負責管理各個節(jié)點的 Manage 節(jié)點主機：
管理節(jié)點負責整個 Cluster 集群中各個節(jié)點的管理工作，包括集群的配置，啟動關(guān)閉各節(jié)點，以及實施數(shù)據(jù)的備份恢復(fù)等。管理節(jié)點會獲取整個 Cluster 環(huán)境中各節(jié)點的狀態(tài)和錯誤信息，并且將各 Cluster 集群中各個節(jié)點的信息反饋給整個集群中其他的所有節(jié)點。由于管理節(jié)點上保存在整個 Cluster 環(huán)境的配置，同時擔任了集群中各節(jié)點的基本溝通工作，所以他必須是最先被啟動的節(jié)點。

b) SQL 層的 SQL 服務(wù)器節(jié)點（后面簡稱為 SQL 節(jié)點），也就是我們常說的 Mysql Server：
主要負責實現(xiàn)一個數(shù)據(jù)庫在存儲層之上的所有事情，比如連接管理，query 優(yōu)化和響應(yīng)，cache 管理等等，只有存儲層的工作交給了 NDB 數(shù)據(jù)節(jié)點去處理了。也就是說，在純粹的 Mysql Cluster 環(huán)境中的 SQL 節(jié)點，可以被認為是一個不需要提供任何存儲引擎的 Mysql服務(wù)器，因為他的存儲引擎有 Cluster 環(huán)境中的 NDB 節(jié)點來擔任。所以，SQL 層各 Mysql 服務(wù)器的啟動與普通的 Mysql 啟動有一定的區(qū)別，必須要添加 ndbcluster 項，可以添加在my.cnf 配置文件中，也可以通過啟動命令行來指定。

c) Storage 層的 NDB 數(shù)據(jù)節(jié)點，也就是上面說的 NDB Cluster：
NDB 是一個內(nèi)存式存儲引擎也就是說，他會將所有的數(shù)據(jù)和索引數(shù)據(jù)都 load 到內(nèi)存中 ，但也會將數(shù)據(jù)持久化到存儲設(shè)備上。不過，最新版本，已經(jīng)支持用戶自己選擇數(shù)據(jù)可以不全部 Load 到內(nèi)存中了，這對于有些數(shù)據(jù)量太大或者基于成本考慮而沒有足夠內(nèi)存空間來存放所有數(shù)據(jù)的用戶來說的確是一個大好消息。

NDB 節(jié)點主要是實現(xiàn)底層數(shù)據(jù)存儲的功能，保存 Cluster 的數(shù)據(jù)。每一個 NDB 節(jié)點保存完整數(shù)據(jù)的一部分（或者一份完整的數(shù)據(jù)，視節(jié)點數(shù)目和配置而定），在 MySQL CLuster 里面叫做一個 fragment。而每一個 fragment，正常情況來講都會在其他的主機上面有一份（或者多分）完全相同的鏡像存在。這些都是通過配置來完成的，所以只要配置得當，MysqlCluster 在存儲層不會出現(xiàn)單點的問題。

一般來說，NDB 節(jié)點被組織成一個一個的 NDB Group，一個 NDB Group 實際上就是一組存有完全相同的物理數(shù)據(jù)的 NDB 節(jié)點群。上面提到了 NDB 各個節(jié)點對數(shù)據(jù)的組織，可能每個節(jié)點都存有全部的數(shù)據(jù)也可能只保存一部分數(shù)據(jù)，主要是受節(jié)點數(shù)目和參數(shù)來控制的。首先在 Mysql Cluster 主配置文件（在管理節(jié)點上面，一般為 config.ini）中，有一個非常重要的參數(shù)叫 NoOfReplicas，這個參數(shù)指定了每一份數(shù)據(jù)被冗余存儲在不同節(jié)點上面的份數(shù)，該參數(shù)一般至少應(yīng)該被設(shè)置成 2，也只需要設(shè)置成 2 就可以了。因為正常來說，兩個互為冗余的節(jié)點同時出現(xiàn)故障的概率還是非常小的，當然如果機器和內(nèi)存足夠多的話，也可以繼續(xù)增大。一個節(jié)點上面是保存所有的數(shù)據(jù)還是一部分數(shù)據(jù)，還受到存儲節(jié)點數(shù)目的限制。NDB 存儲引擎首先保證 NoOfReplicas 參數(shù)配置的要求對數(shù)據(jù)冗余，來使用存儲節(jié)點，然后再根據(jù)節(jié)點數(shù)目將數(shù)據(jù)分段來繼續(xù)使用多余的 NDB 節(jié)點，分段的數(shù)目為節(jié)點總數(shù)除以 NoOfReplicas 所得。

其他存儲引擎介紹

1. Merge 存儲引擎：

MERGE 存儲引擎，在 MySQL 用戶手冊中也提到了，也被大家認識為 MRG_MyISAM 引擎。Why？因為 MERGE 存儲引擎可以簡單的理解為其功能就是實現(xiàn)了對結(jié)構(gòu)相同的 MyISAM 表 ，通過一些特殊的包裝對外提供一個單一的訪問入口，以達到減小應(yīng)用的復(fù)雜度的目的。要創(chuàng)建MERGE 表，不僅僅基表的結(jié)構(gòu)要完全一致，包括字段的順序，基表的索引也必須完全一致。

MERGE 表本身并不存儲數(shù)據(jù)，僅僅只是為多個基表提供一個同意的存儲入口。所以在創(chuàng)建 MERGE 表的時候，MySQL 只會生成兩個較小的文件，一個是.frm 的結(jié)構(gòu)定義文件，還有一個.MRG 文件，用于存放參與 MERGE 的表的名稱（包括所屬數(shù)據(jù)庫 schema）。之所以需要有所屬數(shù)據(jù)庫的 schema，是因為 MERGE 表不僅可以實現(xiàn)將 Merge 同一個數(shù)據(jù)庫中的表，還可以Merge 不同數(shù)據(jù)庫中的表，只要是權(quán)限允許，并且在同一個 mysqld 下面，就可以進行 Merge。MERGE 表在被創(chuàng)建之后，仍然可以通過相關(guān)命令來更改底層的基表。MERGE 表不僅可以提供讀取服務(wù)，也可以提供寫入服務(wù)。要讓 MERGE 表提供可 INSERT服務(wù)，必須在在表被創(chuàng)建的時候就指明 INSERT 數(shù)據(jù)要被寫入哪一個基表，可以通過insert_method 參數(shù)來控制。如果沒有指定該參數(shù)，任何嘗試往 MERGE 表中 INSERT 數(shù)據(jù)的操作，都會出錯。此外，無法通過 MERGE 表直接使用基表上面的全文索引，要使用全文索引 ，必須通過基表本身的存取才能實現(xiàn)。

2. Memory 存儲引擎：

Memory 存儲引擎，通過名字就很容易讓人知道，他是一個將數(shù)據(jù)存儲在內(nèi)存中的存儲引擎。Memory 存儲引擎不會將任何數(shù)據(jù)存放到磁盤上，僅僅存放了一個表結(jié)構(gòu)相關(guān)信息的.frm 文件在磁盤上面。所以一旦 MySQL Crash 或者主機 Crash 之后，Memory 的表就只剩下一個結(jié)構(gòu)了。Memory 表支持索引，并且同時支持 Hash 和 B－Tree 兩種格式的索引。由于是存放在內(nèi)存中，所以 Memory 都是按照定長的空間來存儲數(shù)據(jù)的，而且不支持 BLOB 和 TEXT類型的字段。Memory 存儲引擎實現(xiàn)頁級鎖定。既然所有數(shù)據(jù)都存放在內(nèi)存中，那么他對內(nèi)存的消耗量是可想而知的。在 MySQL 的用戶手冊上面有這樣一個公式來計算 Memory 表實際需要消耗的內(nèi)存大小：

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. BDB 存儲引擎：

BDB 存儲引擎全稱為 BerkeleyDB 存儲引擎，和 Innodb 一樣，也不是 MySQL 自己開發(fā)實現(xiàn)的一個存儲引擎，而是由 Sleepycat Software 所提供，當然，也是開源存儲引擎，同樣支持事務(wù)安全。BDB 存儲引擎的數(shù)據(jù)存放也是每個表兩個物理文件，一個.frm 和一個.db 的文件，數(shù)據(jù)和索引信息都是存放在.db 文件中。此外，BDB 為了實現(xiàn)事務(wù)安全，也有自己的 redo 日 志 ，和 Innodb 一樣，也可以通過參數(shù)指定日志文件存放的位置。在鎖定機制方面，BDB 和 Memory存儲引擎一樣，實現(xiàn)頁級鎖定。由于 BDB 存儲引擎實現(xiàn)了事務(wù)安全，那么他肯定也需要有自己的 check point 機 制 。BDB在每次啟動的時候，都會做一次 check point，并且將之前的所有 redo 日志清空。在運行過程中，我們也可以通過執(zhí)行 flush logs 來手工對 BDB 進行 check point 操作。

4. FEDERATED 存儲引擎：

FEDERATED 存儲引擎所實現(xiàn)的功能，和 Oracle 的 DBLINK 基本相似，主要用來提供對遠程 MySQL 服務(wù)器上面的數(shù)據(jù)的訪問借口。如果我們使用源碼編譯來安裝 MySQL，那么必須手工指定啟用FEDERATED 存儲引擎才行，因為 MySQL 默認是不起用該存儲引擎的。當我們創(chuàng)建一個 FEDERATED 表的時候，僅僅在本地創(chuàng)建了一個表的結(jié)構(gòu)定義信息的文件而已，所有數(shù)據(jù)均實時取自遠程的 MySQL 服務(wù)器上面的數(shù)據(jù)庫。當我們通過 SQL 操作 FEDERATED 表的時候，實現(xiàn)過程基本如下：
a、SQL 調(diào)用被本地發(fā)布
b、MySQL 處理器 API（數(shù)據(jù)以處理器格式）
c、MySQL 客戶端 API（數(shù)據(jù)被轉(zhuǎn)換成 SQL 調(diào)用）
d、遠程數(shù)據(jù)庫-> MySQL 客戶端 API
e、轉(zhuǎn)換結(jié)果包（如果有的話）到處理器格式
f、處理器 API -> 結(jié)果行或受行影響的對本地的計數(shù)

5. ARCHIVE 存儲引擎：

ARCHIVE 存儲引擎主要用于通過較小的存儲空間來存放過期的很少訪問的歷史數(shù)據(jù)。ARCHIVE 表不支持索引，通過一個.frm 的結(jié)構(gòu)定義文件，一個.ARZ 的數(shù)據(jù)壓縮文件還有一個.ARM 的 meta 信息文件。由于其所存放的數(shù)據(jù)的特殊性，ARCHIVE 表不支持刪除，修改操作，僅支持插入和查詢操作。鎖定機制為行級鎖定。

6. BLACKHOLE 存儲引擎：

BLACKHOLE 存儲引擎是一個非常有意思的存儲引擎，功能恰如其名，就是一個“黑洞”。就像我們 unix 系統(tǒng)下面的“/dev/null”設(shè)備一樣，不管我們寫入任何信息，都是有去無回 。那么BLACKHOLE存儲引擎對我們有什么用呢？在我最初接觸MySQL的時候我也有過同樣的疑問，不知道 MySQL 提供這樣一個存儲引擎給我們的用意為何？但是后來在又一次數(shù)據(jù)的遷移過程中，正是 BLACKHOLE 給我?guī)砹朔浅４蟮墓π?。在那次?shù)據(jù)遷移過程中，由于數(shù)據(jù)需要經(jīng)過一個中轉(zhuǎn)的 MySQL 服務(wù)器做一些相關(guān)的轉(zhuǎn)換操作，然后再通過復(fù)制移植到新的服務(wù)器上
面?？僧敃r我沒有足夠的空間來支持這個中轉(zhuǎn)服務(wù)器的運作。這時候就顯示出 BLACKHOLE的功效了，他不會記錄下任何數(shù)據(jù)，但是會在 binlog 中記錄下所有的 sql。而這些 sql 最終都是會被復(fù)制所利用，并實施到最終的 slave 端。

BLACKHOLE 存儲引擎其他幾個用途如下：
a、SQL 文件語法的驗證。
b、來自二進制日志記錄的開銷測量，通過比較允許二進制日志功能的 BLACKHOLE 的性能與禁止二進制日志功能的 BLACKHOLE 的性能。
c、因為 BLACKHOLE 本質(zhì)上是一個“no-op” 存儲引擎，它可能被用來查找與存儲引擎自身不相關(guān)的性能瓶頸。

7. CSV 存儲引擎：

CSV 存儲引擎實際上操作的就是一個標準的 CSV 文件，他不支持索引。起主要用途就是大家有些時候可能會需要通過數(shù)據(jù)庫中的數(shù)據(jù)導(dǎo)出成一份報表文件，而 CSV 文件是很多軟件都支持的一種較為標準的格式，所以我們可以通過先在數(shù)據(jù)庫中建立一張 CVS 表，然后將生成的報表信息插入到該表，即可得到一份 CSV 報表文件了