今天，開始寫數據庫。***篇，說說MySQL兩個最常用的存儲引擎，MyISAM和InnoDB。照自己的理解，把一些知識點總結出來，不只說知識點，多講“為什么”。

[[241510]]

一、關于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

• 有where條件，count(*)兩個存儲引擎性能差不多
• 不要使用全文索引，應當使用《索引外置》的設計方案
• 事務影響性能，強一致性要求才使用事務
• 不用外鍵，由應用程序來保證完整性
• 不***索引，InnoDB也不能用行鎖

結論

在大數據量，高并發量的互聯網業務場景下，請使用InnoDB:

• 行鎖，對提高并發幫助很大
• 事務，對數據一致性幫助很大

這兩個點，是InnoDB最吸引人的地方。

幾個小的知識點，希望大家有收獲。有說的不對的，歡迎大家指正，共同討論。

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文