MySQL儲存引擎比較
轉載自:http://menglimengwai.iteye.com/blog/464667
MySQL常用的儲存引擎為MyISAM、InnoDB、MEMORY、MERGE，其中InnoDB提供事務安全表，其他儲存引擎都是非事務安全表。
MyISAM是MySQL的預設儲存引擎。MyISAM不支援事務、也不支援外來鍵，但其訪問速度快，對事務完整性沒有要求。
InnoDB儲存引擎提供了具有提交、回滾和崩潰恢復能力的事務安全。但是比起MyISAM儲存引擎，InnoDB寫的處理效率差一些並且會佔用更多的磁碟空間以保留資料和索引。
MEMORY儲存引擎使用存在記憶體中的內容來建立表。每個MEMORY表只實際對應一個磁碟檔案。MEMORY型別的表訪問非常得快，因為它的資料是放在記憶體中的，並且預設使用HASH索引。但是一旦服務關閉，表中的資料就會丟失掉。
MERGE儲存引擎是一組MyISAM表的組合，這些MyISAM表必須結構完全相同。MERGE表本身沒有資料，對MERGE型別的表進行查詢、更新、刪除的操作，就是對內部的MyISAM表進行的。
MyISAM表還支援3中不同的儲存格式：
1 靜態表
2 動態表
3 壓縮表
靜態表是預設的儲存格式，靜態表中的欄位都是非變長的欄位，優點是：儲存非常迅速，容易快取，出現故障容易恢復；缺點是：佔用的空間通常比動態表多。（注意： 在儲存時，列的寬度不足時，用空格補足，當時在訪問的時候並不會得到這些空格）
動態表的欄位是變長的，優點是：佔用的空間相對較少，但是頻繁地更新刪除記錄會產生碎片，需要定期改善效能，並且出現故障的時候恢復相對比較困難。
壓縮表佔用磁碟空間小，每個記錄是被單獨壓縮的，所以只有非常小的訪問開支。
MySQL支援外來鍵儲存引擎只有InnoDB，在建立外來鍵的時候，要求附表必須有對應的索引，子表在建立外來鍵的時候也會自動建立對應的索引。
InnoDB儲存方式為兩種：1 使用共享表空間儲存 2 使用多表空間
MEMORY型別的儲存引擎主要用於那些內容變化不頻繁的程式碼表，或者作為統計操作的中間結果表，便於高效地堆中間結果進行分析並得到最終的統計結果。對MEMORY儲存引擎的表進行更新操作要謹慎，因為資料並沒有實際寫入到磁碟中，所以一定要對下次重新啟動服務後如何獲得這些修改後的資料有所考慮。
MERGE用於將一系列等同的MyISAM表以邏輯方式組合在一起，並作為一個物件引用它。MERGE表的優點在於可以突破對單個MyISAM表大小的限制，通過將不同的表分佈在多個磁碟上，可以有效的改善MERGE表的訪問效率。
另一篇:-)
這段時間在看《High Performance MySQL》，看到儲存引擎這個地方感到很多細節比較陌生，所以總結小記一些
為了適應各種不同的執行環境，MYSQL提供了多種不同的儲存引擎（Storage Engine ）,在應用程式開發這個層面上，開發者可以根據不同的需求選擇適合的Storage Engine
方案，更為靈活的是，你可以根據每張表將要儲存資料的特點，選擇不同的Storage Engine,也就是說，在一個MYSQL資料庫中，可以混合使用多種不同的Storage Engine
首先小瞥一下MySQL的體系結構，在最高抽象層度下，可以用Garlan & Shaw的分層結構體系來表示（左）
其中應用層為所有RDBMS使用者提供使用者介面，邏輯層包括了所有核心功能的實現，物理層則負責將資料儲存在硬體裝置上。
圖中右側更為具體的描述了邏輯層的組成，查詢處理子系統、事務管理子系統、恢復管理子系統和儲存管理子系統共同組成了MySQL的邏輯層。相信Storage Engine的位置是在Storage Management處，既Storage Engine屬於Storage Management子系統的一部分
為了讓思路更清晰一些，下面給出一幅比較全面的體系結構圖（或更確切的說是流程圖，只是忽略了反饋）
上面三幅圖來自於一篇非官方（不保證百分百的正確）的MySQL體系結構的報告，與《High Performance MySQL
連線上圖中第二層和第三層之間的介面是並不針對任何儲存引擎的單一API,.大概由20個基本的類似“啟動事務，返回結果集”等函式組成。儲存引擎並不處理SQL，相互之間也不通訊，它們的任務只是簡單的響應高層傳來的請求。
儲存引擎各自的一些特點
上面提到的四種儲存引擎都有各自適用的環境，這取決於它們獨有的一些特徵。主要體現在效能、事務、併發控制、參照完整性、快取、 故障恢復，備份及回存等幾個方面
目前比較普及的儲存引擎是MyISAM和InnoDB.而MyISAM又是絕大部分Web應用的首選。MyISAM與InnoDB的主要的不同點在於效能和事務控制上。
MyISAM是早期ISAM(Indexed Sequential Access Method,我現在用的MySQL5.0已經不支援ISAM了）的擴充套件實現，ISAM被設計為適合處理讀頻率遠大於寫頻率這樣一種情況，因此ISAM以及後來的MyISAM都沒有考慮對事物的支援，排除了TPM，不需要事務記錄，ISAM的查詢效率相當可觀，而且記憶體佔用很少。MyISAM在繼承了這類優點的同時，與時俱進的提供了大量實用的新特性和相關工具。例如考慮到併發控制，提供了表級鎖，雖然MyISAM本身不支援容錯，但可以通過myisamchk進行故障恢復。而且由於MyISAM是每張表使用各自獨立的儲存檔案（MYD資料檔案和MYI索引檔案），使得備份及恢復十分方便（拷貝覆蓋即可），而且還支援線上恢復。
所以如果你的應用是不需要事務，處理的只是基本的CRUD操作，那麼MyISAM是不二選擇
InnoDB被設計成適用於高併發讀寫的情況.使用MVCC(Multi-Version Concurrency Control)以及行級鎖來提供遵從ACID的事務支援。InnoDB支援外來鍵參照完整性，具備故障恢復能力。另外 InnoDB的效能其實還是不錯的，特別是在處理大資料量的情況下,用官方的話說就是： InnoDB的CPU效率是其他基於磁碟的關係資料庫儲存引擎所不能比的。不過InnoDB的備份恢復要麻煩一點，除非你使用了4.1以後版本提供的Mulit-tablespace支援，因為InnoDB和MyISAM不同，他的資料檔案並不是獨立對應於每張表的。而是使用的共享表空間，簡單的拷貝覆蓋方法對他不適用，必須在停掉MYSQL後對進行資料恢復。使用Per-Table Tablespacesd，使其每張表對應一個獨立的表空間檔案，則情況要簡單很多。
一般來說，如果需要事務支援，並且有較高的併發讀寫頻率，InnoDB是不錯的選擇。要是併發讀寫頻率不高的話，其實可以考慮BDB,但由於在MySQL5.1及其以後版本中，將不再提供BDB支援。這個選項也就沒有了
至於Heap和BDB（Berkeley DB），相對來說，普及率不如前兩種，但在有些情況下，還是挺適用的
Heap儲存引擎就是將資料儲存在記憶體中，由於沒有磁碟I./O的等待，速度極快。但由於是記憶體儲存引擎，所做的任何修改在伺服器重啟後都將消失。
Heap挺適合做測試的時候使用
BDB是MySQL第一款事務安全的儲存引擎。在Berkeley DB database library的基礎上建立，同樣是事務安全的，但BDB的普及率顯然不及InnoDB，因為大多數在MySQL中尋找支援事務的儲存引擎的同時也在找支援MVCC或是行級鎖定儲存引擎，而BDB只支援Page-level Lock。
附上一張《High Performance MySQL》 中的各儲存引擎的特性表
Attribute
MyISAM
Heap
BDB
InnoDB
|
Transactions |
No |
No |
Yes |
Yes |
|
Lock granularity |
Table |
Table |
Page (8 KB) |
Row |
|
Storage |
Split files |
In-memory |
Single file per table |
Tablespace(s) |
|
Isolation levels |
None |
None |
Read committed |
All |
|
Portable format |
Yes |
N/A |
No |
Yes |
|
Referential integrity |
No |
No |
No |
Yes |
|
Primary key with data |
No |
No |
Yes |
Yes |
|
MySQL caches data records |
No |
Yes |
Yes |
Yes |
|
Availability |
All versions |
All versions |
MySQL-Max |
All Versions |