MyISAM是MySQL的默認數(shù)據(jù)庫引擎（5.5版之前）搀捷，由早期的ISAM（Indexed Sequential Access Method：有索引的順序訪問方法）所改良星掰。雖然性能極佳，但卻有一個缺點：不支持事務處理（transaction）指煎。不過蹋偏，在這幾年的發(fā)展下便斥，MySQL也導入了InnoDB（另一種數(shù)據(jù)庫引擎）至壤，以強化參考完整性與并發(fā)違規(guī)處理機制，后來就逐漸取代MyISAM枢纠。
InnoDB像街，是MySQL的數(shù)據(jù)庫引擎之一黎棠，為MySQL AB發(fā)布binary的標準之一。InnoDB由Innobase Oy公司所開發(fā)镰绎，2006年五月時由甲骨文公司并購脓斩。與傳統(tǒng)的ISAM與MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事務（Transaction）功能畴栖，類似于PostgreSQL随静。目前InnoDB采用雙軌制授權，一是GPL授權吗讶，另一是專有軟件授權燎猛。
MyISAM和InnoDB兩者之間有著明顯區(qū)別，簡單梳理如下:
1) 事務支持
MyISAM不支持事務照皆，而InnoDB支持重绷。InnoDB的AUTOCOMMIT默認是打開的，即每條SQL語句會默認被封裝成一個事務膜毁，自動提交昭卓，這樣會影響速度，所以最好是把多條SQL語句顯示放在begin和commit之間瘟滨，組成一個事務去提交候醒。
MyISAM是非事務安全型的，而InnoDB是事務安全型的杂瘸，默認開啟自動提交火焰，宜合并事務，一同提交胧沫，減小數(shù)據(jù)庫多次提交導致的開銷昌简，大大提高性能。
2) 存儲結(jié)構
MyISAM：每個MyISAM在磁盤上存儲成三個文件绒怨。第一個文件的名字以表的名字開始纯赎，擴展名指出文件類型。.frm文件存儲表定義南蹂。數(shù)據(jù)文件的擴展名為.MYD (MYData)犬金。索引文件的擴展名是.MYI (MYIndex)。
InnoDB：所有的表都保存在同一個數(shù)據(jù)文件中（也可能是多個文件六剥，或者是獨立的表空間文件）晚顷，InnoDB表的大小只受限于操作系統(tǒng)文件的大小，一般為2GB疗疟。
3) 存儲空間
MyISAM：可被壓縮该默，存儲空間較小。支持三種不同的存儲格式：靜態(tài)表(默認，但是注意數(shù)據(jù)末尾不能有空格，會被去掉)、動態(tài)表岭埠、壓縮表裹刮。
InnoDB：需要更多的內(nèi)存和存儲音榜，它會在主內(nèi)存中建立其專用的緩沖池用于高速緩沖數(shù)據(jù)和索引。
4) 可移植性捧弃、備份及恢復
MyISAM：數(shù)據(jù)是以文件的形式存儲赠叼，所以在跨平臺的數(shù)據(jù)轉(zhuǎn)移中會很方便。在備份和恢復時可單獨針對某個表進行操作违霞。
InnoDB：免費的方案可以是拷貝數(shù)據(jù)文件梅割、備份 binlog，或者用 mysqldump葛家，在數(shù)據(jù)量達到幾十G的時候就相對痛苦了户辞。
5) 事務支持
MyISAM：強調(diào)的是性能，每次查詢具有原子性,其執(zhí)行數(shù)度比InnoDB類型更快癞谒，但是不提供事務支持底燎。
InnoDB：提供事務支持事務，外部鍵等高級數(shù)據(jù)庫功能弹砚。 具有事務(commit)双仍、回滾(rollback)和崩潰修復能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。
6) AUTO_INCREMENT
MyISAM：可以和其他字段一起建立聯(lián)合索引桌吃。引擎的自動增長列必須是索引朱沃，如果是組合索引，自動增長可以不是第一列茅诱，他可以根據(jù)前面幾列進行排序后遞增逗物。
InnoDB：InnoDB中必須包含只有該字段的索引。引擎的自動增長列必須是索引瑟俭，如果是組合索引也必須是組合索引的第一列翎卓。
7) 表鎖差異
MyISAM：只支持表級鎖，用戶在操作myisam表時摆寄，select失暴，update，delete微饥，insert語句都會給表自動加鎖逗扒，如果加鎖以后的表滿足insert并發(fā)的情況下，可以在表的尾部插入新的數(shù)據(jù)欠橘。
InnoDB：支持事務和行級鎖矩肩，是innodb的最大特色。行鎖大幅度提高了多用戶并發(fā)操作的新能简软。但是InnoDB的行鎖蛮拔，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全表的痹升。
MyISAM鎖的粒度是表級建炫，而InnoDB支持行級鎖定。簡單來說就是, InnoDB支持數(shù)據(jù)行鎖定疼蛾，而MyISAM不支持行鎖定肛跌，只支持鎖定整個表。即MyISAM同一個表上的讀鎖和寫鎖是互斥的察郁，MyISAM并發(fā)讀寫時如果等待隊列中既有讀請求又有寫請求衍慎，默認寫請求的優(yōu)先級高，即使讀請求先到皮钠，所以MyISAM不適合于有大量查詢和修改并存的情況稳捆，那樣查詢進程會長時間阻塞。因為MyISAM是鎖表麦轰，所以某項讀操作比較耗時會使其他寫進程餓死乔夯。
8) 全文索引
MyISAM：支持(FULLTEXT類型的)全文索引
InnoDB：不支持(FULLTEXT類型的)全文索引，但是innodb可以使用sphinx插件支持全文索引款侵，并且效果更好末荐。
全文索引是指對char、varchar和text中的每個詞（停用詞除外）建立倒排序索引新锈。MyISAM的全文索引其實沒啥用甲脏，因為它不支持中文分詞，必須由使用者分詞后加入空格再寫到數(shù)據(jù)表里妹笆，而且少于4個漢字的詞會和停用詞一樣被忽略掉块请。
另外，MyIsam索引和數(shù)據(jù)分離拳缠，InnoDB在一起负乡，MyIsam天生非聚簇索引，最多有一個unique的性質(zhì)脊凰，InnoDB的數(shù)據(jù)文件本身就是主鍵索引文件抖棘，這樣的索引被稱為“聚簇索引”
9) 表主鍵
MyISAM：允許沒有任何索引和主鍵的表存在，索引都是保存行的地址狸涌。
InnoDB：如果沒有設定主鍵或者非空唯一索引切省，就會自動生成一個6字節(jié)的主鍵(用戶不可見)，數(shù)據(jù)是主索引的一部分帕胆，附加索引保存的是主索引的值朝捆。InnoDB的主鍵范圍更大，最大是MyISAM的2倍懒豹。
10) 表的具體行數(shù)
MyISAM：保存有表的總行數(shù)芙盘，如果select count() from table;會直接取出出該值驯用。
InnoDB：沒有保存表的總行數(shù)(只能遍歷)，如果使用select count() from table儒老；就會遍歷整個表蝴乔，消耗相當大，但是在加了wehre條件后驮樊，myisam和innodb處理的方式都一樣薇正。
- CURD操作
MyISAM：如果執(zhí)行大量的SELECT，MyISAM是更好的選擇囚衔。
InnoDB：如果你的數(shù)據(jù)執(zhí)行大量的INSERT或UPDATE挖腰，出于性能方面的考慮，應該使用InnoDB表练湿。DELETE 從性能上InnoDB更優(yōu)猴仑，但DELETE FROM table時，InnoDB不會重新建立表肥哎，而是一行一行的刪除宁脊，在innodb上如果要清空保存有大量數(shù)據(jù)的表，最好使用truncate table這個命令贤姆。
12) 外鍵
MyISAM：不支持
InnoDB：支持
13) 查詢效率
沒有where的count()使用MyISAM要M比InnoDB快得多榆苞。因為yISAM內(nèi)置了一個計數(shù)器，count()時它直接從計數(shù)器中讀霞捡，而InnoDB必須掃描全表坐漏。所以在InnoDB上執(zhí)行count()時一般要伴隨where，且where中要包含主鍵以外的索引列碧信。為什么這里特別強調(diào)“主鍵以外”赊琳？因為InnoDB中primary index是和raw data存放在一起的，而secondary index則是單獨存放砰碴，然后有個指針指向primary key躏筏。所以只是count()的話使用secondary index掃描更快，而primary key則主要在掃描索引同時要返回raw data時的作用較大呈枉。MyISAM相對簡單趁尼，所以在效率上要優(yōu)于InnoDB，小型應用可以考慮使用MyISAM猖辫。
通過上述的分析酥泞，基本上可以考慮使用InnoDB來替代MyISAM引擎了，原因是InnoDB自身很多良好的特點啃憎，比如事務支持芝囤、存儲 過程、視圖、行級鎖定等等悯姊，在并發(fā)很多的情況下羡藐，相信InnoDB的表現(xiàn)肯定要比MyISAM強很多。另外悯许，任何一種表都不是萬能的仆嗦，只用恰當?shù)尼槍I(yè)務類型來選擇合適的表類型，才能最大的發(fā)揮MySQL的性能優(yōu)勢岸晦。如果不是很復雜的Web應用欧啤，非關鍵應用睛藻，還是可以繼續(xù)考慮MyISAM的启上，這個具體情況可以自己斟酌。
MyISAM和InnoDB兩者的應用場景：
- MyISAM管理非事務表店印。它提供高速存儲和檢索冈在，以及全文搜索能力。如果應用中需要執(zhí)行大量的SELECT查詢按摘，那么MyISAM是更好的選擇包券。
- InnoDB用于事務處理應用程序，具有眾多特性炫贤，包括ACID事務支持溅固。如果應用中需要執(zhí)行大量的INSERT或UPDATE操作，則應該使用InnoDB兰珍，這樣可以提高多用戶并發(fā)操作的性能侍郭。
但是實際場景中，針對具體問題需要具體分析掠河，一般而言可以遵循以下幾個問題：
- 數(shù)據(jù)庫是否有外鍵亮元？
- 是否需要事務支持？
- 是否需要全文索引唠摹？
- 數(shù)據(jù)庫經(jīng)常使用什么樣的查詢模式爆捞？在寫多讀少的應用中還是Innodb插入性能更穩(wěn)定，在并發(fā)情況下也能基本勾拉，如果是對讀取速度要求比較快的應用還是選MyISAM煮甥。
- 數(shù)據(jù)庫的數(shù)據(jù)有多大？ 大尺寸傾向于innodb藕赞，因為事務日志苛秕，故障恢復。
