MyISAM和InnoDB的區別
一、關於count(*)
知識點：MyISAM會直接儲存總行數，InnoDB則不會，需要按行掃描。
潛臺詞是，對於select count(*) from t; 如果資料量大，MyISAM會瞬間返回，而InnoDB則會一行行掃描。
實踐：資料量大的表，InnoDB不要輕易select count(*)，效能消耗極大。
常見坑：只有查詢全表的總行數，MyISAM才會直接返回結果，當加了where條件後，兩種儲存引擎的處理方式類似。
例如： t_user(uid, uname, age, sex);
- uid PK
- age index
select count() where age<18 and sex='F';
查詢未成年少女個數，兩種儲存引擎的處理方式類似，都需要進行索引掃描。*
啟示
二、關於全文索引
知識點：MyISAM支援全文索引，InnoDB5.6之前不支援全文索引。
實踐：不管哪種儲存引擎，在資料量大併發量大的情況下，都不應該使用資料庫自帶的全文索引，會導致小量請求佔用大量資料庫資源，而要使用《索引外接》的架構設計方法。
啟示：大資料量+高併發量的業務場景，全文索引，MyISAM也不是最優之選。
三、關於事務
知識點：MyISAM不支援事務，InnoDB支援事務。
實踐：事務是選擇InnoDB非常誘人的原因之一，它提供了commit，rollback，崩潰修復等能力。在系統異常崩潰時，MyISAM有一定機率造成檔案損壞，這是非常煩的。但是，事務也非常耗效能，會影響吞吐量，建議只對一致性要求較高的業務使用複雜事務。
畫外音：Can't open file 'XXX.MYI'. 碰到過麼？
小技巧：MyISAM可以通過lock table表鎖，來實現類似於事務的東西，但對資料庫效能影響較大，強烈不推薦使用。
四、關於外來鍵
知識點：MyISAM不支援外來鍵，InnoDB支援外來鍵。
實踐：不管哪種儲存引擎，在資料量大併發量大的情況下，都不應該使用外來鍵，而建議由應用程式保證完整性。
五、關於行鎖與表鎖
知識點：MyISAM只支援表鎖，InnoDB可以支援行鎖。
分析： MyISAM：執行讀寫SQL語句時，會對錶加鎖，所以資料量大，併發量高時，效能會急劇下降。 InnoDB：細粒度行鎖，在資料量大，併發量高時，效能比較優異。
實踐：網上常常說，select+insert的業務用MyISAM，因為MyISAM在檔案尾部順序增加記錄速度極快。樓主的建議是，絕大部分業務是混合讀寫，只要資料量和併發量較大，一律使用InnoDB。
常見坑： InnoDB的行鎖是實現在索引上的，而不是鎖在物理行記錄上。潛臺詞是，如果訪問沒有命中索引，也無法使用行鎖，將要退化為表鎖。
畫外音：Oracle的行鎖實現機制不同。
例如： t_user(uid, uname, age, sex) innodb;
- uid PK
- 無其他索引
update t_user set age=10 where uid=1; 命中索引，行鎖。
update t_user set age=10 where uid != 1; 未命中索引，表鎖。
update t_user set age=10 where name='shenjian'; 無索引，表鎖。
啟示：InnoDB務必建好索引，否則鎖粒度較大，會影響併發。
|
引擎/區別 |
MyISAM |
InnoDB |
|
構成上的區別： |
每個MyISAM在磁碟上儲存成三個檔案。第一個檔案的名字以表的名字開始，副檔名指出檔案型別。 .frm檔案儲存表定義。 資料檔案的副檔名為.MYD (MYData)。 索引檔案的副檔名是.MYI (MYIndex)。 |
基於磁碟的資源是InnoDB表空間資料檔案和它的日誌檔案，InnoDB 表的大小隻受限於作業系統檔案的大小，一般為 2GB |
|
事務處理上方面: |
MyISAM型別的表強調的是效能，其執行數度比InnoDB型別更快，但是不提供事務支援 |
InnoDB提供事務支援事務，外部鍵等高階資料庫功能 |
|
SELECT UPDATE,INSERT，Delete操作 |
如果執行大量的SELECT，MyISAM是更好的選擇 |
1.如果你的資料執行大量的INSERT或UPDATE，出於效能方面的考慮，應該使用InnoDB表 2.DELETE FROM table時，InnoDB不會重新建立表，而是一行一行的刪除。 3.LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，匯入資料後再改成InnoDB表，但是對於使用的額外的InnoDB特性（例如外來鍵）的表不適用 |
|
對AUTO_INCREMENT的操作 |
每表一個AUTO_INCREMEN列的內部處理。 MyISAM為INSERT和UPDATE操作自動更新這一列。這使得AUTO_INCREMENT列更快（至少10%）。在序列頂的值被刪除之後就不能再利用。(當AUTO_INCREMENT列被定義為多列索引的最後一列，可以出現重使用從序列頂部刪除的值的情況）。 AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置 對於AUTO_INCREMENT型別的欄位，InnoDB中必須包含只有該欄位的索引，但是在MyISAM表中，可以和其他欄位一起建立聯合索引 更好和更快的auto_increment處理 |
如果你為一個表指定AUTO_INCREMENT列，在資料詞典裡的InnoDB表控制代碼包含一個名為自動增長計數器的計數器，它被用在為該列賦新值。 自動增長計數器僅被儲存在主記憶體中，而不是存在磁碟上 關於該計算器的演算法實現，請參考 AUTO_INCREMENT列在InnoDB裡如何工作 |
|
表的具體行數 |
select count(*) from table,MyISAM只要簡單的讀出儲存好的行數，注意的是，當count(*)語句包含 where條件時，兩種表的操作是一樣的 |
InnoDB 中不儲存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行 |
|
鎖 |
表鎖 |
提供行鎖(locking on row level)，提供與 Oracle 型別一致的不加鎖讀取(non-locking read in SELECTs)，另外，InnoDB表的行鎖也不是絕對的，如果在執行一個SQL語句時MySQL不能確定要掃描的範圍，InnoDB表同樣會鎖全表，例如update table set num=1 where name like “%aaa%” |
總結
在大資料量，高併發量的網際網路業務場景下，對於MyISAM和InnoDB
- 有where條件，count(*)兩個儲存引擎效能差不多
- 不要使用全文索引，應當使用《索引外接》的設計方案
- 事務影響效能，強一致性要求才使用事務
- 不用外來鍵，由應用程式來保證完整性
- 不命中索引，InnoDB也不能用行鎖
結論
在大資料量，高併發量的網際網路業務場景下，請使用InnoDB:
- 行鎖，對提高併發幫助很大
- 事務，對資料一致性幫助很大