MyIsam和InnoDB的區別 InnoDB與Myisam的六大區別

我的看法：

　　1.最主要的差異就是Innodb 支持事務處理與外鍵和行級鎖.而MyISAM不支持

     　因此有用到事務處理和外鍵的，要用Innodb

      2. InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行

　　   但若是帶有where ，兩種的查詢方式就同樣了【因此這點區別不大】

　　3.穩定性，方便的擴展性和高可用性來講的話，MyISAM比較好

      4.寫入和修改操做，Innodb性能比較好。查詢操做，MyISAM更好。

        【注意：最近實際測試，myisam的寫入速度比innodb的快】

         實例：1.6w的數據，1.從innodb類型表裏轉移到myisam類型表用時48秒（期間有些過濾處理）；2.從myisam類型表裏轉移到myisam類型表裏33秒；

                  3.從myisam類型表或innodb類型表裏轉移到innodb類型表，33分鐘左右。

　　

 

 

白話講MyIsam和InnoDB的區別

"MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持"
 
這是網上對MyISAM和InnoDB的解釋,很抽象吧,咱們用白話的方式解釋一下
 
其實也比較簡單
 
所謂事務處理，就是原子性操做。
打個比方，支持事務處理的Innodb表，建設一箇中，發帖是給積分的。你發了一個帖子執行一個insert語句，來插入帖子內容，插入後就要執行一個update語句來增長你的積分。假設一種特殊狀況忽然發生，insert成功了，update操做卻沒有被執行。也就是說你發了帖子卻沒有增長相應的積分。這就會形成用戶不滿。若是使用了事務處理，insert和update都放入到事務中去執行，這個時候，只有當insert和update兩條語句都執行生成的時候纔會將數據更新、寫入到中，若是其中任何一條語句失敗，那麼就會回滾爲初始狀態，不執行寫入。這樣就保證了insert和update確定是一同執行的。
 
 
mysiam表不支持事務處理，同時mysiam表不支持外鍵。外鍵不用說了吧？不知道的話，去網上查吧。
同時，在執行數據庫寫入的操做（insert,update,delete）的時候，mysiam表會鎖表，而innodb表會鎖行。通俗點說，就是你執行了一個update語句，那麼mysiam表會將整個表都鎖住，其餘的insert和delete、update都會被拒之門外，等到這個update語句執行完成後纔會被依次執行。
 
 
而鎖行，就是說，你執行update語句是，只會將這一條記錄進行鎖定，只有針對這條記錄的其餘寫入、更新操做會被阻塞並等待這條update語句執行完畢後再執行，針對其餘記錄的寫入操做不會有影響。
 
 
所以，當你的數據庫有大量的寫入、更新操做而查詢比較少或者數據完整性要求比較高的時候就選擇innodb表。當你的數據庫主要以查詢爲主，相比較而言更新和寫入比較少，而且業務方面數據完整性要求不那麼嚴格，就選擇mysiam表。由於mysiam表的查詢操做效率和速度都比innodb要快

 

 

 

InnoDB與Myisam的六大區別

 

MyISAM	InnoDB
構成上的區別：	每一個MyISAM在磁盤上存儲成三個文件。第一個文件的名字以表的名字開始，擴展名指出文件類型。   .frm文件存儲表定義。   數據文件的擴展名爲.MYD (MYData)。   索引文件的擴展名是.MYI (MYIndex)。	基於磁盤的資源是InnoDB表空間數據文件和它的日誌文件，InnoDB 表的大小隻受限於操做系統文件的大小，通常爲 2GB
事務處理上方面:	MyISAM類型的表強調的是性能，其執行數度比InnoDB類型更快，可是不提供事務支持	InnoDB提供事務支持事務，外部鍵等高級數據庫功能
SELECT   UPDATE,INSERT，Delete操做	若是執行大量的SELECT，MyISAM是更好的選擇	1.若是你的數據執行大量的INSERT或UPDATE，出於性能方面的考慮，應該使用InnoDB表   2.DELETE   FROM table時，InnoDB不會從新創建表，而是一行一行的刪除。   3.LOAD   TABLE FROM MASTER操做對InnoDB是不起做用的，解決方法是首先把InnoDB表改爲MyISAM表，導入數據後再改爲InnoDB表，可是對於使用的額外的InnoDB特性（例如外鍵）的表不適用
對AUTO_INCREMENT的操做	每表一個AUTO_INCREMEN列的內部處理。   MyISAM爲INSERT和UPDATE操做自動更新這一列。這使得AUTO_INCREMENT列更快（至少10%）。在序列頂的值被刪除以後就不能再利用。(當AUTO_INCREMENT列被定義爲多列索引的最後一列，能夠出現重使用從序列頂部刪除的值的狀況）。   AUTO_INCREMENT值可用ALTER TABLE或myisamch來重置   對於AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，可是在MyISAM表中，能夠和其餘字段一塊兒創建聯合索引   更好和更快的auto_increment處理	若是你爲一個表指定AUTO_INCREMENT列，在數據詞典裏的InnoDB表句柄包含一個名爲自動增加計數器的計數器，它被用在爲該列賦新值。   自動增加計數器僅被存儲在主內存中，而不是存在磁盤上   關於該計算器的算法實現，請參考   AUTO_INCREMENT列在InnoDB裏如何工做
表的具體行數	select count(*) from table,MyISAM只要簡單的讀出保存好的行數，注意的是，當count(*)語句包含   where條件時，兩種表的操做是同樣的	InnoDB 中不保存表的具體行數，也就是說，執行select count(*) from table時，InnoDB要掃描一遍整個表來計算有多少行
鎖	表鎖	提供行鎖(locking on row level)，提供與 Oracle 類型一致的不加鎖讀取(non-locking read in    SELECTs)，另外，InnoDB表的行鎖也不是絕對的，若是在執行一個SQL語句時MySQL不能肯定要掃描的範圍，InnoDB表一樣會鎖全表，例如update table set num=1 where name like 「%aaa%」

 

實例講解

 

兩種類型最主要的差異就是Innodb 支持事務處理與外鍵和行級鎖.而MyISAM不支持.因此MyISAM每每就容易被人認爲只適合在小項目中使用。

 

我做爲使用MySQL的用戶角度出發，Innodb和MyISAM都是比較喜歡的，可是從我目前運維的數據庫平臺要達到需求：99.9%的穩定性，方便的擴展性和高可用性來講的話，MyISAM絕對是個人首選。

 

緣由以下：

 

一、首先我目前平臺上承載的大部分項目是讀多寫少的項目，而MyISAM的讀性能是比Innodb強很多的。

 

二、MyISAM的索引和數據是分開的，而且索引是有壓縮的，內存使用率就對應提升了很多。能加載更多索引，而Innodb是索引和數據是緊密捆綁的，沒有使用壓縮從而會形成Innodb比MyISAM體積龐大不小。

 

三、從平臺角度來講，常常隔1，2個月就會發生應用開發人員不當心update一個表where寫的範圍不對，致使這個表無法正經常使用了，這個時候MyISAM的優越性就體現出來了，隨便從當天拷貝的壓縮包取出對應表的文件，隨便放到一個數據庫目錄下，而後dump成sql再導回到主庫，並把對應的binlog補上。若是是Innodb，恐怕不可能有這麼快速度，別和我說讓Innodb按期用導出xxx.sql機制備份，由於我平臺上最小的一個數據庫實例的數據量基本都是幾十G大小。

 

四、從我接觸的應用邏輯來講，select count(*) 和order by 是最頻繁的，大概能佔了整個sql總語句的60%以上的操做，而這種操做Innodb其實也是會鎖表的，不少人覺得Innodb是行級鎖，那個只是where對它主鍵是有效，非主鍵的都會鎖全表的。

 

五、還有就是常常有不少應用部門須要我給他們按期某些表的數據，MyISAM的話很方便，只要發給他們對應那表的frm.MYD,MYI的文件，讓他們本身在對應版本的數據庫啓動就行，而Innodb就須要導出xxx.sql了，由於光給別人文件，受字典數據文件的影響，對方是沒法使用的。

 

六、若是和MyISAM比insert寫操做的話，Innodb還達不到MyISAM的寫性能，若是是針對基於索引的update操做，雖然MyISAM可能會遜色Innodb,可是那麼高併發的寫，從庫可否追的上也是一個問題，還不如經過多實例分庫分表架構來解決。

 

七、若是是用MyISAM的話，merge引擎能夠大大加快應用部門的開發速度，他們只要對這個merge表作一些select count(*)操做，很是適合大項目總量約幾億的rows某一類型(如日誌，調查統計)的業務表。

 

固然Innodb也不是絕對不用，用事務的項目如模擬炒股項目，我就是用Innodb的，活躍用戶20多萬時候，也是很輕鬆應付了，所以我我的也是很喜歡Innodb的，只是若是從數據庫平臺應用出發，我仍是會首選MyISAM。

 

另外，可能有人會說你MyISAM沒法抗太多寫操做，可是我能夠經過架構來彌補，說個我現有用的數據庫平臺容量：主從數據總量在幾百T以上，天天十多億 pv的動態頁面，還有幾個大項目是經過數據接口方式調用未算進pv總數，(其中包括一個大項目由於初期memcached沒部署,致使單臺數據庫天天處理 9千萬的查詢)。而個人總體數據庫服務器平均負載都在0.5-1左右。