InnoDB和MyISAM是很多人在使用MySQL時最常用的兩個表類型,這兩個表類型各有優劣,5.7之後就不壹樣了
1、事務和外鍵
InnoDB具有事務,支持4個事務隔離級別,回滾,崩潰修復能力和多版本並發的事務安全,包括ACID。如果應用中需要執行大量的INSERT或UPDATE操作,則應該使用InnoDB,這樣可以提高多用戶並發操作的性能
MyISAM管理非事務表。它提供高速存儲和檢索,以及全文搜索能力。如果應用中需要執行大量的SELECT查詢,那麽MyISAM是更好的選擇
2、全文索引
Innodb不支持全文索引,如果壹定要用的話,最好使用sphinx等搜索引擎。myisam對中文支持的不是很好
不過新版本的Innodb已經支持了
3、鎖
mysql支持三種鎖定級別,行級、頁級、表級;
MyISAM支持表級鎖定,提供與 Oracle 類型壹致的不加鎖讀取(non-locking read in SELECTs)
InnoDB支持行級鎖,InnoDB表的行鎖也不是絕對的,如果在執行壹個SQL語句時MySQL不能確定要掃描的範圍,InnoDB表同樣會鎖全表,註意間隙鎖的影響
例如update table set num=1 where name like “%aaa%”
4、存儲
MyISAM在磁盤上存儲成三個文件。第壹個文件的名字以表的名字開始,擴展名指出文件類型, .frm文件存儲表定義,數據文件的擴展名為.MYD,? 索引文件的擴展名是.MYI
InnoDB,基於磁盤的資源是InnoDB表空間數據文件和它的日誌文件,InnoDB 表的大小只受限於操作系統文件的大小
註意:MyISAM表是保存成文件的形式,在跨平臺的數據轉移中使用MyISAM存儲會省去不少的麻煩
5、索引
InnoDB(索引組織表)使用的聚簇索引、索引就是數據,順序存儲,因此能緩存索引,也能緩存數據
MyISAM(堆組織表)使用的是非聚簇索引、索引和文件分開,隨機存儲,只能緩存索引
6、並發
MyISAM讀寫互相阻塞:不僅會在寫入的時候阻塞讀取,MyISAM還會在讀取的時候阻塞寫入,但讀本身並不會阻塞另外的讀
InnoDB?讀寫阻塞與事務隔離級別相關
7、場景選擇
MyISAM
不需要事務支持(不支持)
並發相對較低(鎖定機制問題)
數據修改相對較少(阻塞問題),以讀為主
數據壹致性要求不是非常高
盡量索引(緩存機制)
調整讀寫優先級,根據實際需求確保重要操作更優先
啟用延遲插入改善大批量寫入性能
盡量順序操作讓insert數據都寫入到尾部,減少阻塞
分解大的操作,降低單個操作的阻塞時間
降低並發數,某些高並發場景通過應用來進行排隊機制
對於相對靜態的數據,充分利用Query Cache可以極大的提高訪問效率
MyISAM的Count只有在全表掃描的時候特別高效,帶有其他條件的count都需要進行實際的數據訪問
InnoDB?
需要事務支持(具有較好的事務特性)
行級鎖定對高並發有很好的適應能力,但需要確保查詢是通過索引完成
數據更新較為頻繁的場景
數據壹致性要求較高
硬件設備內存較大,可以利用InnoDB較好的緩存能力來提高內存利用率,盡可能減少磁盤 IO
主鍵盡可能小,避免給Secondary index帶來過大的空間負擔
避免全表掃描,因為會使用表鎖
盡可能緩存所有的索引和數據,提高響應速度
在大批量小插入的時候,盡量自己控制事務而不要使用autocommit自動提交
合理設置innodb_flush_log_at_trx_commit參數值,不要過度追求安全性
避免主鍵更新,因為這會帶來大量的數據移動
8、其它細節
1)InnoDB 中不保存表的具體行數,註意的是,當count(*)語句包含 where條件時,兩種表的操作是壹樣的
2)對於AUTO_INCREMENT類型的字段,InnoDB中必須包含只有該字段的索引,但是在MyISAM表中,可以和其他字段壹起建立聯合索引, 如果妳為壹個表指定AUTO_INCREMENT列,在數據詞典裏的InnoDB表句柄包含壹個名為自動增長計數器的計數器,它被用在為該列賦新值。自動增長計數器僅被存儲在主內存中,而不是存在磁盤
3)DELETE FROM table時,InnoDB不會重新建立表,而是壹行壹行的刪除
4)LOAD TABLE FROM MASTER操作對InnoDB是不起作用的,解決方法是首先把InnoDB表改成MyISAM表,導入數據後再改成InnoDB表,但是對於使用的額外的InnoDB特性(例如外鍵)的表不適用
5)如果執行大量的SELECT,MyISAM是更好的選擇,如果妳的數據執行大量的INSERT或UPDATE,出於性能方面的考慮,應該使用InnoDB表
7、為什麽MyISAM會比Innodb 的查詢速度快
InnoDB?在做SELECT的時候,要維護的東西比MYISAM引擎多很多;
1)InnoDB?要緩存數據和索引,MyISAM只緩存索引塊,這中間還有換進換出的減少
2)innodb尋址要映射到塊,再到行,MyISAM記錄的直接是文件的OFFSET,定位比INNODB要快
3)InnoDB?還需要維護MVCC壹致;雖然妳的場景沒有,但他還是需要去檢查和維護
MVCC ( Multi-Version Concurrency Control )多版本並發控制
InnoDB?:通過為每壹行記錄添加兩個額外的隱藏的值來實現MVCC,這兩個值壹個記錄這行數據何時被創建,另外壹個記錄這行數據何時過期(或者被刪除)。但是InnoDB並不存儲這些事件發生時的實際時間,相反它只存儲這些事件發生時的系統版本號。這是壹個隨著事務的創建而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行數據的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是REPEATABLE READ時這種策略是如何應用到特定的操作的
SELECT InnoDB必須每行數據來保證它符合兩個條件
1、InnoDB必須找到壹個行的版本,它至少要和事務的版本壹樣老(也即它的版本號不大於事務的版本號)。這保證了不管是事務開始之前,或者事務創建時,或者修改了這行數據的時候,這行數據是存在的。
2、這行數據的刪除版本必須是未定義的或者比事務版本要大。這可以保證在事務開始之前這行數據沒有被刪除。
8、mysql性能討論
MyISAM最為人垢病的缺點就是缺乏事務的支持
InnoDB 的磁盤性能很令人擔心
MySQL 缺乏良好的 tablespace?
兩種類型最主要的差別就是Innodb 支持事務處理與外鍵和行級鎖.而MyISAM不支持.所以MyISAM往往就容易被人認為只適合在小項目中使用。
我作為使用MySQL的用戶角度出發,Innodb和MyISAM都是比較喜歡的,但是從我目前運維的數據庫平臺要達到需求:99.9%的穩定性,方便的擴展性和高可用性來說的話,MyISAM絕對是我的首選。
原因如下:
1、首先我目前平臺上承載的大部分項目是讀多寫少的項目,而MyISAM的讀性能是比Innodb強不少的。
2、MyISAM的索引和數據是分開的,並且索引是有壓縮的,內存使用率就對應提高了不少。能加載更多索引,而Innodb是索引和數據是緊密捆綁的,沒有使用壓縮從而會造成Innodb比MyISAM體積龐大不小。
3、從平臺角度來說,經常隔1,2個月就會發生應用開發人員不小心update壹個表where寫的範圍不對,導致這個表沒法正常用了,這個時候MyISAM的優越性就體現出來了,隨便從當天拷貝的壓縮包取出對應表的文件,隨便放到壹個數據庫目錄下,然後dump成sql再導回到主庫,並把對應的binlog補上。如果是Innodb,恐怕不可能有這麽快速度,別和我說讓Innodb定期用導出xxx.sql機制備份,因為我平臺上最小的壹個數據庫實例的數據量基本都是幾十G大小。
4、從我接觸的應用邏輯來說,select count(*) 和order by 是最頻繁的,大概能占了整個sql總語句的60%以上的操作,而這種操作Innodb其實也是會鎖表的,很多人以為Innodb是行級鎖,那個只是where對它主鍵是有效,非主鍵的都會鎖全表的。
5、還有就是經常有很多應用部門需要我給他們定期某些表的數據,MyISAM的話很方便,只要發給他們對應那表的frm.MYD,MYI的文件,讓他們自己在對應版本的數據庫啟動就行,而Innodb就需要導出xxx.sql了,因為光給別人文件,受字典數據文件的影響,對方是無法使用的。
6、如果和MyISAM比insert寫操作的話,Innodb還達不到MyISAM的寫性能,如果是針對基於索引的update操作,雖然MyISAM可能會遜色Innodb,但是那麽高並發的寫,從庫能否追的上也是壹個問題,還不如通過多實例分庫分表架構來解決。
7、如果是用MyISAM的話,merge引擎可以大大加快應用部門的開發速度,他們只要對這個merge表做壹些select count(*)操作,非常適合大項目總量約幾億的rows某壹類型(如日誌,調查統計)的業務表。
當然Innodb也不是絕對不用,用事務的項目如模擬炒股項目,我就是用Innodb的,活躍用戶20多萬時候,也是很輕松應付了,因此我個人也是很喜歡Innodb的,只是如果從數據庫平臺應用出發,我還是會首選MyISAM。
另外,可能有人會說妳MyISAM無法抗太多寫操作,但是我可以通過架構來彌補,說個我現有用的數據庫平臺容量:主從數據總量在幾百T以上,每天十多億 pv的動態頁面,還有幾個大項目是通過數據接口方式調用未算進pv總數,(其中包括壹個大項目因為初期memcached沒部署,導致單臺數據庫每天處理 9千萬的查詢)。而我的整體數據庫服務器平均負載都在0.5-1左右。