InnoDB和MyISAM是很多人在使用MySQL時最常用的兩個表型別，這兩個表型別各有優劣，5.7之後就不一樣了

1、事務和外來鍵

InnoDB具有事務，支援4個事務隔離級別，回滾，崩潰修復能力和多版本併發的事務安全，包括ACID。如果應用中需要執行大量的INSERT或UPDATE操作，則應該使用InnoDB，這樣可以提高多使用者併發操作的效能

MyISAM管理非事務表。它提供高速儲存和檢索，以及全文搜尋能力。如果應用中需要執行大量的SELECT查詢，那麼MyISAM是更好的選擇

2、全文索引

Innodb不支援全文索引，如果一定要用的話，最好使用sphinx等搜尋引擎。myisam對中文支援的不是很好

不過新版本的Innodb已經支援了

3、鎖

mysql支援三種鎖定級別，行級、頁級、表級;

MyISAM支援表級鎖定，提供與 Oracle 型別一致的不加鎖讀取(non-locking read in SELECTs)

InnoDB支援行級鎖，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表，注意間隙鎖的影響

例如update table set num=1 where name like “%aaa%”

4、儲存

MyISAM在磁碟上儲存成三個檔案。第一個檔案的名字以表的名字開始，副檔名指出檔案型別， .frm檔案儲存表定義，資料檔案的副檔名為.MYD，  索引檔案的副檔名是.MYI

InnoDB，基於磁碟的資源是InnoDB表空間資料檔案和它的日誌檔案，InnoDB 表的大小隻受限於作業系統檔案的大小

注意：MyISAM表是儲存成檔案的形式，在跨平臺的資料轉移中使用MyISAM儲存會省去不少的麻煩

5、索引

InnoDB（索引組織表）使用的聚簇索引、索引就是資料，順序儲存，因此能快取索引，也能快取資料

MyISAM（堆組織表）使用的是非聚簇索引、索引和檔案分開，隨機儲存，只能快取索引

6、併發

MyISAM讀寫互相阻塞：不僅會在寫入的時候阻塞讀取，MyISAM還會在讀取的時候阻塞寫入，但讀本身並不會阻塞另外的讀

InnoDB 讀寫阻塞與事務隔離級別相關

7、場景選擇

MyISAM

• 不需要事務支援（不支援）
• 併發相對較低（鎖定機制問題）
• 資料修改相對較少（阻塞問題），以讀為主
• 資料一致性要求不是非常高

1. 儘量索引（快取機制）
2. 調整讀寫優先順序，根據實際需求確保重要操作更優先
3. 啟用延遲插入改善大批量寫入效能
4. 儘量順序操作讓insert資料都寫入到尾部，減少阻塞
5. 分解大的操作，降低單個操作的阻塞時間
6. 降低併發數，某些高併發場景通過應用來進行排隊機制
7. 對於相對靜態的資料，充分利用Query Cache可以極大的提高訪問效率
8. MyISAM的Count只有在全表掃描的時候特別高效，帶有其他條件的count都需要進行實際的資料訪問

InnoDB 

• 需要事務支援（具有較好的事務特性）
• 行級鎖定對高併發有很好的適應能力，但需要確保查詢是通過索引完成
• 資料更新較為頻繁的場景
• 資料一致性要求較高
• 硬體裝置記憶體較大，可以利用InnoDB較好的快取能力來提高記憶體利用率，儘可能減少磁碟 IO

1. 主鍵儘可能小，避免給Secondary index帶來過大的空間負擔
2. 避免全表掃描，因為會使用表鎖
3. 儘可能快取所有的索引和資料，提高響應速度
4. 在大批量小插入的時候，儘量自己控制事務而不要使用autocommit自動提交
5. 合理設定innodb_flush_log_at_trx_commit引數值，不要過度追求安全性
6. 避免主鍵更新，因為這會帶來大量的資料移動

8、其它細節

1）InnoDB 中不儲存表的具體行數，注意的是，當count(*)語句包含 where條件時，兩種表的操作是一樣的

2）對於AUTO_INCREMENT型別的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引， 如果你為一個表指定AUTO_INCREMENT列，在資料詞典裡的InnoDB表控制代碼包含一個名為自動增長計數器的計數器，它被用在為該列賦新值。自動增長計數器僅被儲存在主記憶體中，而不是存在磁碟

3）DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除

4）LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，匯入資料後再改成InnoDB表，但是對於使用的額外的InnoDB特性(例如外來鍵)的表不適用

5）如果執行大量的SELECT，MyISAM是更好的選擇，如果你的資料執行大量的INSERT或UPDATE，出於效能方面的考慮，應該使用InnoDB表

7、為什麼MyISAM會比Innodb 的查詢速度快

InnoDB 在做SELECT的時候，要維護的東西比MYISAM引擎多很多；

1）InnoDB 要快取資料和索引，MyISAM只快取索引塊，這中間還有換進換出的減少

2）innodb定址要對映到塊，再到行，MyISAM記錄的直接是檔案的OFFSET，定位比INNODB要快

3）InnoDB 還需要維護MVCC一致；雖然你的場景沒有，但他還是需要去檢查和維護

MVCC ( Multi-Version Concurrency Control )多版本併發控制

InnoDB ：通過為每一行記錄新增兩個額外的隱藏的值來實現MVCC，這兩個值一個記錄這行資料何時被建立，另外一個記錄這行資料何時過期（或者被刪除）。但是InnoDB並不儲存這些事件發生時的實際時間，相反它只儲存這些事件發生時的系統版本號。這是一個隨著事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行資料的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是REPEATABLE READ時這種策略是如何應用到特定的操作的

SELECT InnoDB必須每行資料來保證它符合兩個條件

1、InnoDB必須找到一個行的版本，它至少要和事務的版本一樣老(也即它的版本號不大於事務的版本號)。這保證了不管是事務開始之前，或者事務建立時，或者修改了這行資料的時候，這行資料是存在的。

2、這行資料的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行資料沒有被刪除。

8、mysql效能討論

MyISAM最為人垢病的缺點就是缺乏事務的支援

InnoDB 的磁碟效能很令人擔心

MySQL 缺乏良好的 tablespace 

兩種型別最主要的差別就是Innodb 支援事務處理與外來鍵和行級鎖.而MyISAM不支援.所以MyISAM往往就容易被人認為只適合在小專案中使用。

我作為使用MySQL的使用者角度出發，Innodb和MyISAM都是比較喜歡的，但是從我目前運維的資料庫平臺要達到需求：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某一型別(如日誌，調查統計)的業務表。

當然Innodb也不是絕對不用，用事務的專案如模擬炒股專案，我就是用Innodb的，活躍使用者20多萬時候，也是很輕鬆應付了，因此我個人也是很喜歡Innodb的，只是如果從資料庫平臺應用出發，我還是會首選MyISAM。

另外，可能有人會說你MyISAM無法抗太多寫操作，但是我可以通過架構來彌補，說個我現有用的資料庫平臺容量：主從資料總量在幾百T以上，每天十多億 pv的動態頁面，還有幾個大專案是通過資料介面方式呼叫未算進pv總數，(其中包括一個大專案因為初期memcached沒部署,導致單臺數據庫每天處理 9千萬的查詢)。而我的整體資料庫伺服器平均負載都在0.5-1左右。

MyISAM索引實現

MyISAM引擎使用B+Tree作為索引結構，葉節點的data域存放的是資料記錄的地址。如圖： 

這裡設表一共有三列，假設我們以Col1為主鍵，則上圖是一個MyISAM表的主索引（Primary key）示意。可以看出MyISAM的索引檔案僅僅儲存資料記錄的地址。在MyISAM中，主索引和輔助索引（Secondary key）在結構上沒有任何區別，只是主索引要求key是唯一的，而輔助索引的key可以重複。如果我們在Col2上建立一個輔助索引，則此索引的結構如下圖所示： 

同樣也是一顆B+Tree，data域儲存資料記錄的地址。因此，MyISAM中索引檢索的演算法為首先按照B+Tree搜尋演算法搜尋索引，如果指定的Key存在，則取出其data域的值，然後以data域的值為地址，讀取相應資料記錄。 
MyISAM的索引方式也叫做“非聚集”的，之所以這麼稱呼是為了與InnoDB的聚集索引區分。

InnoDB索引實現

雖然InnoDB也使用B+Tree作為索引結構，但具體實現方式卻與MyISAM截然不同。

第一個重大區別是InnoDB的資料檔案本身就是索引檔案。從上文知道，MyISAM索引檔案和資料檔案是分離的，索引檔案僅儲存資料記錄的地址。而在InnoDB中，表資料檔案本身就是按B+Tree組織的一個索引結構，這棵樹的葉節點data域儲存了完整的資料記錄。這個索引的key是資料表的主鍵，因此InnoDB表資料檔案本身就是主索引。

上圖是InnoDB主索引（同時也是資料檔案）的示意圖，可以看到葉節點包含了完整的資料記錄。這種索引叫做聚集索引。因為InnoDB的資料檔案本身要按主鍵聚集，所以InnoDB要求表必須有主鍵（MyISAM可以沒有），如果沒有顯式指定，則MySQL系統會自動選擇一個可以唯一標識資料記錄的列作為主鍵，如果不存在這種列，則MySQL自動為InnoDB表生成一個隱含欄位作為主鍵，這個欄位長度為6個位元組，型別為長整形。

第二個與MyISAM索引的不同是InnoDB的輔助索引data域儲存相應記錄主鍵的值而不是地址。換句話說，InnoDB的所有輔助索引都引用主鍵作為data域。例如，下圖為定義在Col3上的一個輔助索引： 

這裡以英文字元的ASCII碼作為比較準則。聚集索引這種實現方式使得按主鍵的搜尋十分高效，但是輔助索引搜尋需要檢索兩遍索引：首先檢索輔助索引獲得主鍵，然後用主鍵到主索引中檢索獲得記錄。

總結

在資料庫開發中，瞭解不同儲存引擎的索引實現方式對於正確使用和優化索引都非常有幫助。例如，知道了InnoDB的索引實現後，就很容易明白為什麼不建議使用過長的欄位作為主鍵，因為所有輔助索引都引用主索引，過長的主索引會令輔助索引變得過大。再例如，用非單調的欄位作為主鍵在InnoDB中不是個好做法，因為InnoDB資料檔案本身是一顆B+Tree，非單調的主鍵會造成在插入新記錄時資料檔案為了維持B+Tree的特性而頻繁的分裂調整，十分低效，而使用自增欄位作為主鍵則是一個很好的選擇。

轉載整理，如有不足，見諒。