InnoDB，5項最佳實踐，知其所以然？

第一篇，說說MySQL兩個最常用的儲存引擎，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

• 有where條件，count(*)兩個儲存引擎效能差不多
  

• 不要使用全文索引，應當使用《 索引外接 》的設計方案
  

• 事務影響效能，強一致性要求才使用事務
  

• 不用外來鍵，由應用程式來保證完整性
  

• 不命中索引，InnoDB也不能用行鎖
  

結論

在大資料量，高併發量的網際網路業務場景下，請使用InnoDB:

• 行鎖，對提高併發幫助很大
  

• 事務，對資料一致性幫助很大
  

這兩個點，是InnoDB最吸引人的地方。
幾個小的知識點，希望大家有收穫。有說的不對的，歡迎大家指正，共同討論。謝轉。

【本文轉載自微信公眾號架構師之路，原文連結：https://mp.weixin.qq.com/s/JEJcgD36dpKgbUi7xo6DzA，作者：58沈劍】