說在前面：
MyISAM是MySQL的默認數據庫引擎（5.5版之前），由早期的ISAM（Indexed Sequential Access Method：有索引的順序訪問方法）所改良。雖然性能極佳，但卻有一個缺點：不支持事務處理（transaction）。不過，在這幾年的發展下，MySQL也導入了InnoDB（另一種數據庫引擎），以強化參考完整性與併發違規處理機制，後來就逐漸取代MyISAM。
InnoDB，是MySQL的數據庫引擎之一，爲MySQL AB發佈binary的標準之一。InnoDB由Innobase Oy公司所開發，2006年五月時由甲骨文公司併購。與傳統的ISAM與MyISAM相比，InnoDB的最大特色就是支持了ACID兼容的事務（Transaction）功能，類似於PostgreSQL。目前InnoDB採用雙軌制授權，一是GPL授權，另一是專有軟件授權。
MyISAM與InnoDB的區別是什麼？
1、 存儲結構
MyISAM：每個MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型。.frm文件存儲表定義。數據文件的擴展名爲.MYD (MYData)。索引文件的擴展名是.MYI (MYIndex)。
InnoDB：所有的表都保存在同一個數據文件中（也可能是多個文件，或者是獨立的表空間文件），InnoDB表的大小隻受限於操作系統文件的大小，一般爲2GB。
2、 存儲空間
MyISAM：可被壓縮，存儲空間較小。支持三種不同的存儲格式：靜態表(默認，但是注意數據末尾不能有空格，會被去掉)、動態表、壓縮表。
InnoDB：需要更多的內存和存儲，它會在主內存中建立其專用的緩衝池用於高速緩衝數據和索引。
3、 可移植性、備份及恢復
MyISAM：數據是以文件的形式存儲，所以在跨平臺的數據轉移中會很方便。在備份和恢復時可單獨針對某個表進行操作。
InnoDB：免費的方案可以是拷貝數據文件、備份 binlog，或者用 mysqldump，在數據量達到幾十G的時候就相對痛苦了。
4、 事務支持
MyISAM：強調的是性能，每次查詢具有原子性,其執行數度比InnoDB類型更快，但是不提供事務支持。
InnoDB：提供事務支持事務，外部鍵等高級數據庫功能。 具有事務(commit)、回滾(rollback)和崩潰修復能力(crash recovery capabilities)的事務安全(transaction-safe (ACID compliant))型表。
5、 AUTO_INCREMENT
MyISAM：可以和其他字段一起建立聯合索引。引擎的自動增長列必須是索引，如果是組合索引，自動增長可以不是第一列，他可以根據前面幾列進行排序後遞增。
InnoDB：InnoDB中必須包含只有該字段的索引。引擎的自動增長列必須是索引，如果是組合索引也必須是組合索引的第一列。
6、 表鎖差異
MyISAM：只支持表級鎖，用戶在操作myisam表時，select，update，delete，insert語句都會給表自動加鎖，如果加鎖以後的表滿足insert併發的情況下，可以在表的尾部插入新的數據。
InnoDB：支持事務和行級鎖，是innodb的最大特色。行鎖大幅度提高了多用戶併發操作的新能。但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會鎖全表的。
7、 全文索引
MyISAM：支持 FULLTEXT類型的全文索引
InnoDB：不支持FULLTEXT類型的全文索引，但是innodb可以使用sphinx插件支持全文索引，並且效果更好。不支持Geomery。
8、 表主鍵
MyISAM：允許沒有任何索引和主鍵的表存在，索引都是保存行的地址。
InnoDB：如果沒有設定主鍵或者非空唯一索引，就會自動生成一個6字節的主鍵(用戶不可見)，數據是主索引的一部分，附加索引保存的是主索引的值。
9、 表的具體行數
MyISAM：保存有表的總行數，如果select count(*) from table;會直接取出出該值。
InnoDB：沒有保存表的總行數，如果使用select count(*) from table；就會遍歷整個表，消耗相當大，但是在加了wehre條件後，myisam和innodb處理的方式都一樣。
10、 CURD操作
MyISAM：如果執行大量的SELECT，MyISAM是更好的選擇。
InnoDB：如果你的數據執行大量的INSERT或UPDATE，出於性能方面的考慮，應該使用InnoDB表。DELETE 從性能上InnoDB更優，但DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除，在innodb上如果要清空保存有大量數據的表，最好使用truncate table這個命令。
11、 外鍵
MyISAM：不支持
InnoDB：支持
3、全文索引
12、空間索引
空間索引是對空間數據類型的字段建立的索引，MYSQL中的空間數據類型有4種，分別是GEOMETRY、POINT、LINESTRING、POLYGON。
MYSQL使用SPATIAL關鍵字進行擴展，使得能夠用於創建正規索引類型的語法創建空間索引。創建空間索引的列，必須將其聲明爲NOT NULL，空間索引只能在存儲引擎爲MYISAM的表中創建。
結論1：
通過上述的分析，基本上可以考慮使用InnoDB來替代MyISAM引擎了，原因是InnoDB自身很多良好的特點，比如事務支持、存儲 過程、視圖、行級鎖定等等，在併發很多的情況下，相信InnoDB的表現肯定要比MyISAM強很多。另外，任何一種表都不是萬能的，只用恰當的針對業務類型來選擇合適的表類型，才能最大的發揮MySQL的性能優勢。如果不是很複雜的Web應用，非關鍵應用，還是可以繼續考慮MyISAM的，這個具體情況可以自己斟酌。
結論2：
如果數據庫平臺要達到需求：99.9%的穩定性，方便的擴展性和高可用性來說的話，MyISAM絕對是首選。
原因如下：
1、平臺上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強不少的。
2、MyISAM的索引和數據是分開的，並且索引是有壓縮的，內存使用率就對應提高了不少。能加載更多索引，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小。
3、經常隔1，2個月就會發生應用開發人員不小心update一個表where寫的範圍不對，導致這個表沒法正常用了，這個時候MyISAM的優越性就體現出來了，隨便從當天拷貝的壓縮包取出對應表的文件，隨便放到一個數據庫目錄下，然後dump成sql再導回到主庫，並把對應的binlog補上。如果是Innodb，恐怕不可能有這麼快速度，別和我說讓Innodb定期用導出xxx.sql機制備份，因爲最小的一個數據庫實例的數據量基本都是幾十G大小。
4、從接觸的應用邏輯來說，select count(*) 和order by 是最頻繁的，大概能佔了整個sql總語句的60%以上的操作，而這種操作Innodb其實也是會鎖表的，很多人以爲Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。
5、還有就是經常有很多應用部門需要我給他們定期某些表的數據，MyISAM的話很方便，只要發給他們對應那表的frm.MYD,MYI的文件，讓他們自己在對應版本的數據庫啓動就行，而Innodb就需要導出xxx.sql了，因爲光給別人文件，受字典數據文件的影響，對方是無法使用的。
6、如果和MyISAM比insert寫操作的話，Innodb還達不到MyISAM的寫性能，如果是針對基於索引的update操作，雖然MyISAM可能會遜色Innodb,但是那麼高併發的寫，從庫能否追的上也是一個問題，還不如通過多實例分庫分表架構來解決。
7、如果是用MyISAM的話，merge引擎可以大大加快應用部門的開發速度，他們只要對這個merge表做一些select count(*)操作，非常適合大項目總量約幾億的rows某一類型(如日誌，調查統計)的業務表。
測試：
MyISAM和InnoDB
存儲引擎性能差別並不是很大，針對InnoDB來說，影響性能的主要是innodb_flush_log_at_trx_commit這個選項，如果設置爲1 關係，設置爲0效率能夠看到明顯提升，當然，同樣你可以SQL中提交“SET AUTOCOMMIT = 0”來設置達到好的性能。
同時也可以看出值得使用InnoDB來替代myISAM引擎來進行開發，畢竟InnoDB有多數據庫特性、更良好的數據存儲性能和查詢性能MySQL技巧分享
