innodb和myisam的差別化

這個問題想必你們都被問過無數次。今天來總結一下。

1.myisam:

文件結構：frm,myi,myd

frm是文件信息,myi是索引文件，myd是數據文件。（5.6以前只有myisam支持全文檢索。Innodb不支持全文檢索，5.6之後開始支持。）mysiam的索引文件會比innodb的小。由於是分開存放的，因此索引文件進行了壓縮。而innodb是

myisam引擎支持的表鎖，這樣就形成myisam對併發的支持很是差。若是對一張表的數據進行修改，整張表都會被鎖定，其餘進程只能等待該進程釋放後才能對該表進行讀和寫。

select和Insert較innodb來講快。

引用兩篇性能測試文章

2012年

http://www.4wei.cn/archives/1001855

2014年

http://xmgu2008.blog.163.com/blog/static/139122380201402492349491/

從第一篇文章中能夠看到，innodb由於受 innodb_flush_log_at_trx_commit 這個選項的影響，因此自動提交和手動提交性能相去甚遠。

取select count(*)極快，由於myisam表都會有一個叫表狀態的內存空間。這個表的總記錄數，以及修改時間和表的長度等等關鍵數據都是存在一個單獨的內存塊裏面的，當你發起select count(*)這樣的請求，Myisam引擎就不會真的去掃描標表行數了。直接從內存中把該變量讀出來。可是若是你加了一個where條件，並且這個條件的字段不是索引的話，他依然會去掃描表的每一行。

2.Indodb

2.1事物支持

Indodb最重要的一條特性就是支持事務。若是你的業務模型須要原子性的sql操做，須要保證高併發下的數據一致性，就要用到事物。

2.2行級鎖定

對併發的支持較好，只鎖定表中須要修改的那一行，update的速度比myisam引擎速度要快。可是比教消耗資源

3.索引與數據存儲結構對比

3.1.myisam:

primary(主鍵索引)與secondary（二級索引）結構相同，每條索引記錄保存後面的指針（myisam的記錄是一行行的，若是你的記錄有10萬行，那麼myd這個文件就有10萬行，每一行在哪一個位置就是記錄的指針）

數據都是順序插入的。

每次Insert都是在數據最後一行插入。那麼問題來了，若是咱們普通Insert是沒有問題，若是去修改一個變長字段，好比已經有了一百行，須要去修改第一行，第一行原來有一個名稱是姓名，這個字段是變長的，原來是varchar這種類型，原先只寫了10個字節，myisam就用10個字節的空間去存儲，如今要把它寫成20個字節，把一個行變成一個二進制流來說，前幾十個字節表明第一行，你想把第一行變成更多的字節，那它原來的空間就不能存儲了那這個時候，myisam引擎就會再後面追加一個新行，可能其餘字段不變，只把你新的二十個字節的姓名寫到這個表的最後面，那這個時候，記錄這條記錄指針的位置已經變了，那這個時候就須要去修改跟這條記錄相關的全部索引後面的記錄。來保證索引還能指向正確的位置。因此說，你頻繁去更新Myisam表變長字段的話，那其實是很慢的。

Innodb

innodb用的是聚簇索引。聚簇索引的主鍵用的是自增的id爲準，mysiam的主鍵能夠用一個甚至多個字段或者一個字符串當作主鍵，innodb則是不能夠的，innodb只能用自增的數字做爲主鍵，按主鍵的順序去存放索引和數據。Innodb

使用b+樹去排列，左邊比右邊的小，一般他的主鍵和數據是存放在一塊兒的，使用連續的一段空間。你去寫一個新的數據的時候，好比寫到5，他可能在某個節點的左邊子節點，寫6的時候，變成右邊的子節點，按這樣的順序去寫，和myisam不一樣,根據某一行去追加。innodb的secondary(二級索引)保存的是主鍵id,所以數據變更時不須要修改索引。