MySQL各類存儲引擎介紹與適用場景

1.引擎的介紹 

Isam

該引擎在讀取數據方面速度很快，並且不佔用大量的內存和存儲資源；可是 Isam 不支持事務處理、不支持外鍵、不可以容錯、也不支持索引。該引擎在包括MySQL 5.1及其以上版本的數據庫中再也不支持。

Berkeley：

該存儲引擎支持COMMIT和ROLLBACK等事務特性。該引擎在包括MySQL 5.1及其以上版本的數據庫中再也不支持。

CSV:

使用該引擎的MySQL數據庫表會在MySQL安裝目錄data文件夾中的和該表所在數據庫名相同的目錄中生成一個.CSV文件（因此，它能夠將CSV類型的文件當作表進行處理），這種文件是一種普通文本文件，每一個數據行佔用一個文本行。該種類型的存儲引擎不支持索引，即便用該種類型的表沒有主鍵列；另外也不容許表中的字段爲null。csv的編碼轉換須要格外注意。

場景：

這種引擎支持從數據庫中拷入/拷出CSV文件。若是從電子表格軟件輸出一個CSV文件，將其存放在MySQL服務器的數據目錄中，服務器就可以立刻讀取相關的CSV文件。一樣，若是寫數據庫到一個CSV表，外部程序也能夠馬上讀取它。在實現某種類型的日誌記錄時，CSV表做爲一種數據交換格式，特別有用。

HEAP（也稱爲MEMORY）:

該存儲引擎經過在內存中建立臨時表來存儲數據。每一個基於該存儲引擎的表實際對應一個磁盤文件，該文件的文件名和表名是相同的，類型爲.frm。該磁盤文件只存儲表的結構，而其數據存儲在內存中，因此使用該種引擎的表擁有極高的插入、更新和查詢效率。這種存儲引擎默認使用哈希（HASH）索引，其速度比使用B-+Tree型要快，但也可使用B樹型索引。因爲這種存儲引擎所存儲的數據保存在內存中，因此其保存的數據具備不穩定性，好比若是mysqld進程發生異常、重啓或計算機關機等等都會形成這些數據的消失，因此這種存儲引擎中的表的生命週期很短，通常只使用一次。

場景：若是須要該數據庫中一個用於查詢的臨時表。

BLACKHOLE（黑洞引擎）:

該存儲引擎支持事務，並且支持mvcc的行級鎖，寫入這種引擎表中的任何數據都會消失，主要用於作日誌記錄或同步歸檔的中繼存儲，這個存儲引擎除非有特別目的，不然不適合使用。

BLACKHOLE（黑洞引擎）:

場景1：

使用BLACKHOLE存儲引擎的表不存儲任何數據，但若是mysql啓用了二進制日誌，SQL語句被寫入日誌（並被複制到從服務器）。這樣使用BLACKHOLE存儲引擎的mysqld能夠做爲主從複製中的中繼重複器或在其上面添加過濾器機制。例如,假設你的應用須要從服務器側的過濾規則，但傳輸全部二進制日誌數據到從服務器會致使較大的網絡流量。在這種狀況下，在主服務器主機上創建一個僞從服務器進程。

場景2：

若是配置一主多從的話，多個從服務器會在主服務器上分別開啓本身相對應的線程，執行binlogdump命令並且多個此類進程並非共享的。爲了不因多個從服務器同時請求一樣的事件而致使主機資源耗盡，能夠單獨創建一個僞的從服務器或者叫分發服務器。

ARCHIVE:

區別於InnoDB和MyISAM這兩種引擎，ARCHIVE提供了壓縮功能，擁有高效的插入速度，可是這種引擎不支持索引，因此查詢性能較差一些。 archive存儲引擎支持insert、replace和select操做，可是不支持update和delete。

場景1：存儲引擎基本上用於數據歸檔；它的壓縮比很是的高，存儲空間大概是innodb的10-15分之一因此它用來存儲歷史數據很是的適合，因爲它不支持索引同時也不能緩存索引和數據，因此它不適合做爲併發訪問表的存儲引擎。

場景2：因爲高壓縮和快速插入的特色Archive很是適合做爲日誌表的存儲引擎，可是前提是不常常對該表進行查詢操做。

PERFORMANCE_SCHEMA：

該引擎主要用於收集數據庫服務器性能參數。這種引擎提供如下功能：提供進程等待的詳細信息，包括鎖、互斥變量、文件信息；保存歷史的事件彙總信息，爲提供MySQL服務器性能作出詳細的判斷；對於新增和刪除監控事件點都很是容易，並能夠隨意改變mysql服務器的監控週期，例如（CYCLE、MICROSECOND）。 MySQL用戶是不能建立存儲引擎爲PERFORMANCE_SCHEMA的表。

場景： DBA可以較明細得了解性能下降多是因爲哪些瓶頸。

memory

出發點是速度 採用的邏輯存儲介質是內存

Merge

Merge容許將一組使用MyISAM存儲引擎的而且表結構相同（即每張表的字段順序、字段名稱、字段類型、索引定義的順序及其定義的方式必須相同）的數據表合併爲一個表，方便了數據的查詢。

場景：MySQL中沒有物化視圖，視圖的效率極低，故數據倉庫中數據量較大的天天、每週或者每月都建立一個單一的錶的歷史數據的集合能夠經過Merge存儲引擎合併爲一張表。

Federated

該存儲引擎能夠不一樣的Mysql服務器聯合起來，邏輯上組成一個完整的數據庫。這種存儲引擎很是適合數據庫分佈式應用。Federated存儲引擎可使你在本地數據庫中訪問遠程數據庫中的數據，針對federated存儲引擎表的查詢會被髮送到遠程數據庫的表上執行，本地是不存儲任何數據的。

場景： dblink。

缺點：

1.對本地虛擬表的結構修改，並不會修改遠程表的結構

2.truncate 命令，會清除遠程表數據

3. drop命令只會刪除虛擬表，並不會刪除遠程表

4.不支持 alter table 命令

5. select count(), select  from limit M, N 等語句執行效率很是低，數據量較大時存在很嚴重的問題，可是按主鍵或索引列查詢，則很快，如如下查詢就很是慢（假設 id 爲主索引）

select id from db.tablea where id >100 limit 10 ;

而如下查詢就很快：

select id from db.tablea where id >100 and id<150< p="">

6.  若是虛擬虛擬表中字段未創建索引，而實體表中爲此字段創建了索引，此種狀況下，性能也至關差。可是當給虛擬表創建索引後，性能恢復正常。

7. 相似 where name like "str%" limit 1 的查詢，即便在 name 列上建立了索引，也會致使查詢過慢，是由於federated引擎會將全部知足條件的記錄讀取到本，再進行 limit 處理。

Cluster/NDB

該存儲引擎用於多臺數據機器聯合提供服務以提升總體性能和安全性。適合數據量大、安全和性能要求高的場景。

CAP理論。CAP理論(Brewer’s CAP Theorem) ，是說Consistency(一致性), Availability(可用性), Partition tolerance(分佈) 三部分在系統實現只可同時知足二點，無法三者兼顧。若是對"一致性"要求高，且必須要作到"分區"，那麼就要犧牲可用性;而對大型網站，可用性與分區容忍性優先級要高於數據一致性，通常會盡可能朝着 A、P 的方向設計，而後經過其它手段保證對於一致性的商務需求。

InnoDB

適用於更新密集型，支持事務，自動災難恢復，行鎖，外鍵該存儲引擎爲MySQL表提供了ACID事務支持、系統崩潰修復能力和多版本併發控制（即MVCC Multi-Version Concurrency Control）的行鎖支持自增加列（auto_increment）,自增加列的值不能爲空，若是在使用的時候爲空則自動從現有值開始增值，若是有可是比如今的還大，則直接保存這個值支持外鍵（foreign key） ,外鍵所在的表稱爲子表而所依賴的表稱爲父表。該引擎在5.5後的MySQL數據庫中爲默認存儲引擎。

MyISAM

不支持事務，適用於選擇密集型，插入密集型， mysql 默認的引擎 該引擎基於ISAM，除了提供ISAM所沒有的索引和字段管理等大量功能MyISAM還使用一種表鎖機制來優化多個併發讀寫操做，但須要常常運行OPTIMIZE TABLE命令，來恢復被更新機制所浪費的空間，不然碎片也會隨之增長，最終影響數據訪問性能。還有一些有用的擴展，例如用來修復數據庫文件的MyISAM Chk工具和用來恢復浪費空間的 MyISAM Pack工具MyISAM強調了快速讀取操做，主要用於高負載的select，這可能也是MySQL深受Web開發的主要緣由：在Web開發中進行的大量數據操做都是讀，因此大多數虛擬主機提供商和Internet平臺提供商（Internet Presence Provider，IPP）只容許使用MyISAM格式。

MyISAM類型的表支持三種不一樣的存儲結構：靜態型、動態型、壓縮型。

• 靜態表(默認的存儲格式) 表中的字段都是非變長字段，這樣每一個記錄都是固定長度的，這樣存儲
  • 優勢:很是迅速，易緩存，出現故障容易恢復
  • 缺點:佔用的空間一般比動態表多。靜態表在數據存儲時會根據列定義的寬度定義補足空格，可是在訪問的時候並不會獲得這些空格，這些空格在返回給應用以前已經去掉。同時須要注意：在某些狀況下可能須要返回字段後的空格，而使用這種格式時後面到空格會被自動處理掉。
• 動態表 包含變長字段，記錄非固定長度的
  • 優勢:佔用空間較少
  • 缺點:頻繁更新刪除記錄會產生碎片，須要按期執行OPTIMIZE TABLE或myisamchk -r改善性能，而且出現故障的時候恢復相對比較困難
• 壓縮表 由myisamchk工具建立，佔據很是小空間，由於每條記錄都是被單獨壓縮，因此只有很是小的訪問開支

第三方存儲引擎：

Infobright

mysql的列存儲引擎，適用於數據分析和數據倉庫設計。

優勢:

1.查詢性能高        --比普通Mysql 數據庫引擎(MyISAM、InnoDB)  快5-60倍.

2.存儲數據量大   --能存儲的數據量特別大.

3.高壓縮比             --與普通數據庫存放的數據文件相比, 能夠達到55:1

4.不須要創建索引  --省去了大量創建索引的時間.(對於咱們很是有優點)

缺點:

1.不能高併發.最多10個併發

2.Infobright分兩個版本:社區版(ICE,免費)、企業版(IEE,收費),社區版在添加數據時,只支持loaddata , 而不支持.insert,update ,delete . 企業版,則所有支持.

TokuDB

支持數據壓縮，支持高速寫入的一個引擎，可是不適合update多的場景。

XtraDB、PBXT

是Percona公司基於InnoDB的一個改進版本

2.經常使用兩種引擎的選擇

MyISAM與InnoDB

InnoDB和MyISAM是許多人在使用MySQL時最經常使用的兩個表類型，這兩個表類型各有優劣，視具體應用而定。

基本的差異爲： MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，可是不提供事務支持，而InnoDB提供事務支持以及外部鍵等高級數據庫功能。

因此從宏觀來說，事務數據庫關注細節，而數據倉庫關注高層次的彙集，因此，InnoDB更適合做爲線上的事務處理，而MyISAM更適合做爲ROLAP型數據倉庫。

InnoDB引擎適合線上事物型數據庫：

1.InnoDB引擎表是基於B+樹的索引組織表(IOT)；

2.每一個表都須要有一個彙集索引(clustered index)；

3.全部的行記錄都存儲在B+樹的葉子節點(leaf pages of the tree)；

4.基於彙集索引的增、刪、改、查的效率相對是最高的；

5.若是咱們定義了主鍵(PRIMARY KEY)，那麼InnoDB會選擇器做爲彙集索引；

6.若是沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引；

7.若是也沒有這樣的惟一索引，則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

MYISAM引擎適用於ROLAP數據倉庫：

1.讀取效率：數據倉庫的高併發上承載的大部分是讀， MYISAM強調的是性能，每次查詢具備原子性,其執行數度比InnoDB類型更快。

2. 存儲空間：MyISAM： MyISAM的索引和數據是分開的，而且索引是有壓縮的，內存使用率就對應提升了很多。InnoDB：須要更多的內存和存儲，它會在主內存中創建其專用的緩衝池用於高速緩衝數據和索引。

3. MyISAM可移植性備份及恢復：MyISAM：數據是以文件的形式存儲，因此在跨平臺的數據轉移中會很方便。在備份和恢復時可單獨針對某個表進行操做。InnoDB：免費的方案能夠是拷貝數據文件、備份 binlog，或者用 mysqldump，在數據量達到幾十G的時候就相對痛苦了。移植過程當中MyISAM不受字典數據的影響。

4.從接觸的應用邏輯來講，select count(*) 和order by 是最頻繁的，大概能佔了整個sql總語句的60%以上的操做，而這種操做Innodb其實也是會鎖表的，不少人覺得Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。但MYISAM對於count操做只須要在元數據中讀取，不用掃表。

5.若是和MyISAM比insert寫操做的話，Innodb還達不到MyISAM的寫性能，若是是針對基於索引的update操做，雖然MyISAM可能會遜色Innodb,可是那麼高併發的寫，從庫可否追的上也是一個問題，且不建議數據倉庫中頻繁update數據。

6.若是是用MyISAM的話，merge引擎能夠大大加快數據倉庫開發速度，很是適合大項目總量約幾億的rows某一類型(如日誌，調查統計)的業務表。

7.全文索引：MyISAM：支持 FULLTEXT類型的全文索引。InnoDB：不支持FULLTEXT類型的全文索引，可是innodb可使用sphinx插件支持全文索引，而且效果更好。

8.表主鍵：MyISAM：容許沒有任何索引和主鍵的表存在，索引都是保存行的地址。InnoDB：若是沒有設定主鍵或者非空惟一索引，就會自動生成一個6字節的主鍵(用戶不可見)，數據是主索引的一部分，附加索引保存的是主索引的值。

9.對於AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，可是在MyISAM表中，能夠和其餘字段一塊兒創建聯合索引。

10. MyISAM不支持外鍵，需經過其餘方式彌補。

根據引擎特性的優化

如何對InnoDB引擎的表作最優的優化：

1.使用自增列(INT/BIGINT類型)作主鍵，這時候寫入順序是自增的，和B+數葉子節點分裂順序一致，這時候存取效率是最高的

2.該表不指定自增列作主鍵，同時也沒有能夠被選爲主鍵的惟一索引(上面的條件)，這時候InnoDB會選擇內置的ROWID做爲主鍵，寫入順序和ROWID增加順序一致

ps:多出引用，不一一標註。

本文由博客一文多發平臺 OpenWrite 發佈！