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

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 釋出！