InnoDB，5項最佳實踐，知其因此然？

InnoDB，5項最佳實踐，知其因此然？

原創： 58沈劍 架構師之路 5天前

緩存講了一個月《緩存架構，一篇足夠》。今天，開始寫數據庫。

 

第一篇，說說MySQL兩個最經常使用的存儲引擎，MyISAM和InnoDB。照本身的理解，把一些知識點總結出來，不僅說知識點，多講「爲何」。

1、關於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';
查詢未成年少女個數，兩種存儲引擎的處理方式相似，都須要進行索引掃描。

啓示：無論哪一種存儲引擎，都要創建好索引。

2、關於全文索引
知識點：MyISAM支持全文索引，InnoDB5.6以前不支持全文索引。

實踐：無論哪一種存儲引擎，在數據量大併發量大的狀況下，都不該該使用數據庫自帶的全文索引，會致使小量請求佔用大量數據庫資源，而要使用《索引外置》的架構設計方法。

啓示：大數據量+高併發量的業務場景，全文索引，MyISAM也不是最優之選。

3、關於事務
知識點：MyISAM不支持事務，InnoDB支持事務。

實踐：事務是選擇InnoDB很是誘人的緣由之一，它提供了commit，rollback，崩潰修復等能力。在系統異常崩潰時，MyISAM有必定概率形成文件損壞，這是很是煩的。可是，事務也很是耗性能，會影響吞吐量，建議只對一致性要求較高的業務使用復瑣事務。
畫外音：Can't open file 'XXX.MYI'. 碰到過麼？

小技巧：MyISAM能夠經過lock table表鎖，來實現相似於事務的東西，但對數據庫性能影響較大，強烈不推薦使用。

4、關於外鍵
知識點：MyISAM不支持外鍵，InnoDB支持外鍵。

實踐：無論哪一種存儲引擎，在數據量大併發量大的狀況下，都不該該使用外鍵，而建議由應用程序保證完整性。

5、關於行鎖與表鎖
知識點：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最吸引人的地方。

幾個小的知識點，但願你們有收穫。有說的不對的，歡迎你們指正，共同討論。謝轉。

 

相關文章：

《緩存架構，一篇足夠》

《58到家MySQL軍規升級版》