MySQL將每個(gè)數(shù)據(jù)庫（也可以稱為schema）保存為數(shù)據(jù)目錄下的一個(gè)子目錄，創(chuàng)建表時(shí)，MySQL會(huì)在數(shù)據(jù)庫子目錄下創(chuàng)建一個(gè)和表同名的 .frm文件保存表的定義。（也因此MySQL數(shù)據(jù)庫和表的定義對(duì)大小寫的敏感性與具體平臺(tái)密切相關(guān)）

一、InnoDB InnoDB是MySQL的默認(rèn)事務(wù)型引擎，也是最重要，使用最廣泛的存儲(chǔ)引擎。他是用來處理大量的短期事務(wù)，短期事務(wù)大部分情況是正常提交的,很少會(huì)被回滾。 InnoDB的性能和自動(dòng)崩潰恢復(fù)特性，使得它在非事務(wù)型的需求中也很流行。

InnoDB的歷史： 2008年發(fā)布InnoDB plugin,適用于MySQL 5.1 版本，但當(dāng)時(shí)MySQL默認(rèn)還是使用舊的InnoDB引擎。在Oracle收購Sun后發(fā)布的MySQL5.5中才徹底使用InnoDB plugin替代了舊版本的InnoDB

這個(gè)新版本支持一些新特性，例如利用排序創(chuàng)建索引、刪除或者增加索引時(shí)不需要復(fù)制全表數(shù)據(jù)、新的支持壓縮的存儲(chǔ)格式，新的大型列值如BLOB的存儲(chǔ)方式，以及文件格式管理等。

InnoDB的數(shù)據(jù)存儲(chǔ)在表空間中，表空間是由InnoDB管理的一個(gè)黑盒子，由一系列的數(shù)據(jù)文件組成，可以將每個(gè)表的數(shù)據(jù)和索引存放在單獨(dú)的文件中。

采用MVCC來支持高并發(fā)，并且實(shí)現(xiàn)4個(gè)標(biāo)準(zhǔn)的隔離級(jí)別，默認(rèn)級(jí)別是REPEATABLE READ(可重復(fù)讀)，并且通過間隙鎖策略防止幻讀的出現(xiàn)。

InnoDB表示基于聚族索引建立的，聚族索引對(duì)主鍵查詢有很高的性能，若表上的索引較多的話，主鍵應(yīng)當(dāng)盡可能的小。

二、MyISAM 5.1之前版本采用的存儲(chǔ)引擎，提供了包括全文索引，壓縮，空間函數(shù)等，但MyISAM不支持事務(wù)和行級(jí)鎖，而且有個(gè)缺陷就是崩潰后無法安全恢復(fù)。MyISAM會(huì)將表存儲(chǔ)在兩個(gè)文件中：數(shù)據(jù)文件和索引文件，分別以.MYD和.MYI為擴(kuò)展名

三、MySQL內(nèi)建的其他存儲(chǔ)引擎 Archive引擎 只支持Insert和select操作，select查詢需要執(zhí)行全表掃描，適合日志和數(shù)據(jù)采集類應(yīng)用。支持行級(jí)鎖和高并發(fā)的插入。

Blackhole引擎 CSV引擎 Federated引擎 Memory引擎 Merge 引擎 NDB集群引擎

四、如何選擇合適的引擎 大部分情況下，InnoDB都是正確的選擇 除非需要用到某些InnoDB不具備的特性，并且沒有其他辦法可以替代，否則都應(yīng)該優(yōu)先選擇InnoDB引擎。例如，要用到全文索引，建議優(yōu)先考慮InnoDB加上Sphinx的組合。

除非萬不得已，否則建議不要混合使用多種存儲(chǔ)引擎，否則可能帶來一系列復(fù)雜的問題，以及一些潛在的bug和邊界問題。

日志型應(yīng)用

假設(shè)需要實(shí)時(shí)地記錄一臺(tái)中心電話交換機(jī)的每一通電話的日志到MySQL中，或者通過Apache的mod_log_sql模塊將網(wǎng)站的所有訪問信息直接記錄到表中。

這一類應(yīng)用的插入速度有很高的要求，數(shù)據(jù)庫不能成為瓶頸。MyISAM或者Archive存儲(chǔ)引擎對(duì)這類應(yīng)用比較合適，因?yàn)樗麄冮_銷低，插入速度非常快。

做分析報(bào)表時(shí)，利用MySQL內(nèi)置的復(fù)制方案將數(shù)據(jù)復(fù)制一份到備庫，然后在備庫，然后在備庫上執(zhí)行比較消耗時(shí)間和CPU的查詢。

不要輕易相信“MyISAM比InnoDB快”之類的經(jīng)驗(yàn)之談，這個(gè)結(jié)論往往不是絕對(duì)的。在很多我們已知的場景中，InnoDB的速度都可以讓MyISAM望塵莫及。