MySQL存儲引擎選型

1、MySQL的存儲引擎

完整的引擎說明仍是看官方文檔：http://dev.mysql.com/doc/refman/5.6/en/storage-engines.html

這裏介紹一些主要的引擎

 

一、InnoDB存儲引擎

InnoDB是MySQL的默認事務型引擎，它被設計用來處理大量的短時間(short-lived)事務。除非有很是特別的緣由須要使用其餘的存儲引擎，不然應該優先考慮InnoDB引擎。

建議使用MySQL5.5及之後的版本，由於這個版本及之後的版本的InnoDB引擎性能更好。

MySQL4.1之後的版本中，InnoDB能夠將每一個表的數據和索引存放在單獨的文件中。這樣在複製備份崩潰恢復等操做中有明顯優點。能夠經過在my.cnf中增長innodb_file_per_table來開啓這個功能。以下：

[mysqld]
innodb_file_per_table

 

InnoDB採用MVCC來支持高併發，而且實現了四個標準的隔離級別。其默認級別是REPEATABLE READ(可重複讀)，而且經過間隙鎖(next-key locking)策略防止幻讀的出現。(事務和事務隔離級別是另外一個大題目，各自網補吧)。

 

InnoDB是基於聚簇索引創建的，聚簇索引對主鍵查詢有很高的性能。不過它的二級索引(secondary index，非主鍵索引)中必須包含主鍵列，因此若是主鍵列很大的話，其餘的全部索引都會很大。所以表上的索引較多的話，主鍵應當儘量的小。

 

InnoDB的存儲格式是平臺獨立的，能夠將數據和索引文件從Intel平臺複製到Sun SPARC平臺或其餘平臺。

 

InnoDB經過一些機制和工具支持真正的熱備份，MySQL的其餘存儲引擎不支持熱備份。

 

二、MyISAM存儲引擎

MyISAM提供了大量的特性，包括全文索引、壓縮、空間函數(GIS)等，但MyISAM不支持事務和行級鎖，有一個毫無疑問的缺陷就是崩潰後沒法安全恢復。

 

MyISAM會將表存儲在兩個文件在中：數據文件和索引文件，分別是.MYD和.MYI爲擴展名。

在MySQL5.0之前，只能處理4G的數據，5.0中能夠處理256T的數據。

 

在數據再也不進行修改操做時，能夠對MyISAM表進行壓縮，壓縮後能夠提升讀能力，緣由是減小了磁盤I/O。

 

三、Archive引擎

Archive存儲引擎只支持INSERT和SELECT操做，在MySQL5.1以前不支持索引。

Archive表適合日誌和數據採集類應用。

Archive引擎支持行級鎖和專用的緩存區，因此能夠實現高併發的插入，但它不是一個事物型的引擎，而是一個針對高速插入和壓縮作了優化的簡單引擎。

 

四、Blackhole引擎

Blackhole引擎沒有實現任何存儲機制，它會丟棄全部插入的數據，不作任何保存。但服務器會記錄Blackhole表的日誌，因此能夠用於複製數據到備庫，或者簡單地記錄到日誌。但這種應用方式會碰到不少問題，所以並不推薦。

 

五、CSV引擎

CSV引擎能夠將普通的SCV文件做爲MySQL的表來處理，但不支持索引。

CSV引擎能夠做爲一種數據交換的機制，很是有用。

 

六、Federated引擎

Federated引擎是訪問其餘MySQL服務器的一個代理，儘管該引擎看起來提供了一種很好的跨服務器的靈活性，但也常常帶來問題，所以默認是禁用的。

 

七、Memory引擎

若是須要快速地訪問數據，而且這些數據不會被修改，重啓之後丟失也沒有關係，那麼使用Memory表是很是有用。Memory表至少比MyISAM表要快一個數量級。

Memory表是表級鎖，所以併發寫入的性能較低。它不支持BLOB或TEXT類型的列，而且每行的長度是固定的，這可能呆滯部份內存的浪費。

臨時表和Memory表不是一回事。臨時表是指使用CREATE TEMPORARY TABLE語句建立的表，它可使用任何存儲引擎，只在單個鏈接中可見，當鏈接斷開時，臨時表也將不復存在。

 

八、NDB集羣引擎

MySQL服務器、NDB集羣存儲引擎，以及分佈式的、share-nothing的、容災的、高可用的NDB數據庫的組合，被稱爲MySQL集羣(MySQL Cluster)。

 

其餘第三方或社區引擎

XtraDB：是InnoDB的一個改進版本，能夠做爲InnoDB的一個完美的替代產品。

TokuDB：使用了一種新的叫作分形樹(Fractal Trees)的索引數據結構。

Infobright：是最有名的面向列的存儲引擎。

Groonga：是一款全文索引引擎。

OQGraph：該引擎由Open Query研發，支持圖操做(好比查找兩點之間的最短路徑)。

Q4M：該引擎在MySQL內部實現了隊列操做。

SphinxSE：該引擎爲Sphinx全文索引搜索服務器提供了SQL接口。

 

2、選擇合適的引擎

大部分狀況下，InnoDB都是正確的選擇，能夠簡單地概括爲一句話「除非須要用到某些InnoDB不具有的特性，而且沒有其餘辦法能夠替代，不然都應該優先選擇InnoDB引擎」。

除非萬不得已，不然建議不要混合使用多種存儲引擎，不然可能帶來一系列負責的問題，以及一些潛在的bug和邊界問題。

若是應用須要不一樣的存儲引擎，請先考慮如下幾個因素：

事務：

    若是應用須要事務支持，那麼InnoDB(或者XtraDB)是目前最穩定而且通過驗證的選擇。

備份：

    若是能夠按期地關閉服務器來執行備份，那麼備份的因素能夠忽略。反之，若是須要在線熱備份，那麼選擇InnoDB就是基本的要求。

崩潰恢復

    MyISAM崩潰後發生損壞的機率比InnoDB要高不少，並且恢復速度也要慢。

特有的特性

    若是一個存儲引擎擁有一些關鍵的特性，同時卻又缺少一些必要的特性，那麼有時候不得不作折中的考慮，或者在架構設計上作一些取捨。

 

有些查詢SQL在不一樣的引擎上表現不一樣。比較典型的是：

SELECT COUNT(*) FROM table;

對於MyISAM確實會很快，但其餘的可能都不行。

 

3、應用舉例

 

一、日誌型應用

MyISAM或者Archive存儲引擎對這類應用比較合適，由於他們開銷低，並且插入速度很是快。

若是須要對記錄的日誌作分析報表，生成報表的SQL極可能會致使插入效率明顯下降，這時候該怎麼辦？

一種解決方法，是利用MySQL內置的複製方案將數據複製一份到備庫，而後在備庫上執行比較消耗時間和CPU的查詢。固然也能夠在系統負載較低的時候執行報表查詢操做，但應用在不斷變化，若是依賴這個策略可能之後會致使問題。

另外一種方法，在日誌記錄表的名字中包含年和月的信息，這樣能夠在已經沒有插入操做的歷史表上作頻繁的查詢操做，而不會干擾到最新的當前表上的插入操做。

 

二、只讀或者大部分狀況下只讀的表

有些表的數據用於編制類目或者分列清單（如工做崗位），這種應用場景是典型的讀多寫少的業務。若是不介意MyISAM的崩潰恢復問題，選用MyISAM引擎是合適的。（MyISAM只將數據寫到內存中，而後等待操做系統按期將數據刷出到磁盤上）

 

三、訂單處理

涉及訂單處理，支持事務是必要的，InnoDB是訂單處理類應用的最佳選擇。

 

四、大數據量

若是數據增加到10TB以上的級別，可能須要創建數據倉庫。Infobright是MySQL數據倉庫最成功的方案。也有一些大數據庫不適合Infobright，卻可能適合TokuDB。

 

來源：http://toplchx.iteye.com/blog/1941415