mysql中innodb和myisam的區別

InnoDB和MyISAM是不少人在使用MySQL時最經常使用的兩個表類型,這兩個表類型各有優劣,5.7以後就不同了mysql

一、事務和外鍵sql

InnoDB具備事務,支持4個事務隔離級別,回滾,崩潰修復能力和多版本併發的事務安全,包括ACID。若是應用中須要執行大量的INSERT或UPDATE操做,則應該使用InnoDB,這樣能夠提升多用戶併發操做的性能

MyISAM管理非事務表。它提供高速存儲和檢索,以及全文搜索能力。若是應用中須要執行大量的SELECT查詢,那麼MyISAM是更好的選擇緩存

二、全文索引安全

Innodb不支持全文索引,若是必定要用的話,最好使用sphinx等搜索引擎。myisam對中文支持的不是很好併發

不過新版本的Innodb已經支持了高併發

三、鎖性能

mysql支持三種鎖定級別,行級、頁級、表級;搜索引擎

MyISAM支持表級鎖定,提供與 Oracle 類型一致的不加鎖讀取(non-locking read in SELECTs)spa

InnoDB支持行級鎖,InnoDB表的行鎖也不是絕對的,若是在執行一個SQL語句時MySQL不能肯定要掃描的範圍,InnoDB表一樣會鎖全表,注意間隙鎖的影響操作系統

例如update table set num=1 where name like 「%aaa%」

四、存儲

MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始,擴展名指出文件類型, .frm文件存儲表定義,數據文件的擴展名爲.MYD,  索引文件的擴展名是.MYI

InnoDB,基於磁盤的資源是InnoDB表空間數據文件和它的日誌文件,InnoDB 表的大小隻受限於操做系統文件的大小

注意:MyISAM表是保存成文件的形式,在跨平臺的數據轉移中使用MyISAM存儲會省去很多的麻煩

五、索引

InnoDB(索引組織表)使用的聚簇索引、索引就是數據,順序存儲,所以能緩存索引,也能緩存數據

MyISAM(堆組織表)使用的是非聚簇索引、索引和文件分開,隨機存儲,只能緩存索引

六、併發

MyISAM讀寫互相阻塞:不只會在寫入的時候阻塞讀取,MyISAM還會在讀取的時候阻塞寫入,但讀自己並不會阻塞另外的讀

InnoDB 讀寫阻塞與事務隔離級別相關

七、場景選擇

MyISAM

  • 不須要事務支持(不支持)
  • 併發相對較低(鎖定機制問題)
  • 數據修改相對較少(阻塞問題),以讀爲主
  • 數據一致性要求不是很是高
  1. 儘可能索引(緩存機制)
  2. 調整讀寫優先級,根據實際需求確保重要操做更優先
  3. 啓用延遲插入改善大批量寫入性能
  4. 儘可能順序操做讓insert數據都寫入到尾部,減小阻塞
  5. 分解大的操做,下降單個操做的阻塞時間
  6. 下降併發數,某些高併發場景經過應用來進行排隊機制
  7. 對於相對靜態的數據,充分利用Query Cache能夠極大的提升訪問效率
  8. MyISAM的Count只有在全表掃描的時候特別高效,帶有其餘條件的count都須要進行實際的數據訪問

InnoDB 

  • 須要事務支持(具備較好的事務特性)
  • 行級鎖定對高併發有很好的適應能力,但須要確保查詢是經過索引完成
  • 數據更新較爲頻繁的場景
  • 數據一致性要求較高
  • 硬件設備內存較大,能夠利用InnoDB較好的緩存能力來提升內存利用率,儘量減小磁盤 IO
  1. 主鍵儘量小,避免給Secondary index帶來過大的空間負擔
  2. 避免全表掃描,由於會使用表鎖
  3. 儘量緩存全部的索引和數據,提升響應速度
  4. 在大批量小插入的時候,儘可能本身控制事務而不要使用autocommit自動提交
  5. 合理設置innodb_flush_log_at_trx_commit參數值,不要過分追求安全性
  6. 避免主鍵更新,由於這會帶來大量的數據移動

八、其它細節

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表

七、爲何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必須每行數據來保證它符合兩個條件

一、InnoDB必須找到一個行的版本,它至少要和事務的版本同樣老(也即它的版本號不大於事務的版本號)。這保證了不論是事務開始以前,或者事務建立時,或者修改了這行數據的時候,這行數據是存在的。

二、這行數據的刪除版本必須是未定義的或者比事務版本要大。這能夠保證在事務開始以前這行數據沒有被刪除。

八、mysql性能討論

MyISAM最爲人垢病的缺點就是缺少事務的支持

InnoDB 的磁盤性能很使人擔憂

MySQL 缺少良好的 tablespace 

……

相關文章
相關標籤/搜索