基本區別在於MyISAM類型不支持高級處理，比如事務處理，而InnoDB類型支持。MyISAM類型的表強調性能，比InnoDB類型的表更快，但不提供事務支持，而InnoDB提供了事務支持和外鍵等高級數據庫功能。
以下是壹些細節和具體的實現差異:
◆1.InnoDB不支持全文索引。
◆2.InnoDB並不在表中保存具體的行數，也就是說，當執行select count(*) from table時，InnoDB要掃描整個表來計算有多少行，而MyISAM只需要簡單地讀出保存的行數。請註意，當count(*)語句包含where條件時，兩個表的操作是相同的。
◆3.對於AUTO_INCREMENT類型的字段，InnoDB必須只包含該字段的索引，但是在MyISAM表中，可以與其他字段建立聯合索引。
◆ 4.從表中刪除時，InnoDB不會重建表，而是逐行刪除。
◆ 5.◆5。從主操作加載表不適用於InnoDB。解決方法是先把InnoDB表改成MyISAM表，導入數據後再改成InnoDB表，但不適用於有附加InnoDB特性(比如外鍵)的表。
另外，InnoDB表的行鎖不是絕對的。如果MySQL在執行SQL語句時無法確定要掃描的範圍，InnoDB table也會鎖定整個表，例如，Update Table Set num = 1，其中Name類似於“%AAA%”。
這兩種類型的主要區別在於Innodb支持事務處理和外鍵以及行級鎖。MyISAM不支持，所以MyISAM往往容易被認為只適合小項目。
作為使用MySQL的用戶，Innodb和MyISAM都是首選。如果數據庫平臺要滿足要求:99.9%的穩定性、便捷的可擴展性和高可用性，MyISAM絕對是首選。
原因如下：
1，平臺上承載的大部分項目都是讀多寫少的項目，MyISAM的讀性能比Innodb好很多。
2.MyISAM的索引和數據是分離的，索引是壓縮的，所以內存利用率也相應提高。可以加載更多的索引，而Innodb是索引和數據緊密捆綁，沒有壓縮，會讓Innodb比MyISAM更大。
3.每隔1，2個月，經常會發生應用程序開發人員不小心更新了壹個寫在哪裏的範圍錯誤的表，導致該表無法正常使用。這時候米沙姆的優越性就體現出來了。只需從當天復制的壓縮包中取出對應表的文件，隨意放入壹個數據庫目錄中，然後轉儲到sql中，再導入回主庫，補上對應的binlog即可。如果是Innodb，恐怕沒這麽快。不要跟我說通過導出xxx.sql機制讓Innodb定期備份，因為最小的數據庫實例的數據量基本都是幾十吉字節。
4.從contact的應用邏輯來看，select count(*)和order by是最頻繁的操作，占sql語句總數的60%以上。事實上，這個操作Innodb會鎖定表。很多人認為Innodb是行級鎖，認為只有where對其主鍵有效，所有非主鍵都會鎖整個表。
5.還有很多應用部門經常需要我定期給他們某些表的數據。MyISAM非常方便。把FRM的文件發給他們。MYD和MYI對應的那張表，並讓他們在相應版本的數據庫中啟動。Innodb需要導出xxx.sql，因為受字典數據文件的影響，對方不可能使用該文件。
6.如果和MyISAM相比進行insert編寫，Innodb是達不到MyISAM的編寫性能的。如果是基於索引的更新操作，MyISAM可能不如Innodb，但是這麽高的並發寫能不能趕上庫也是個問題。最好通過多實例庫和表架構來解決。
7.如果使用MyISAM，合並引擎可以大大加快應用部門的開發速度。他們只需要在這個合並表上做壹些select count(*)操作，非常適合某壹類rows業務表(如日誌、調查和統計)的總量有幾個億的大型項目。
當然，Innodb也不是絕對沒有必要，使用事務的項目都使用Innodb。另外，可能有人會說，MyISAM無法抵抗太多的寫操作，但是可以通過架構來彌補。