1. 程式人生 > >InnoDB,5項最佳實踐,知其所以然?

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最吸引人的地方。