MySQL中的 MyISAM 讀的效率高，InnoDB 寫的效率高，原理是什麼？（只針對這兩種存儲引擎的對比）

01-29

當年面試的時候，面試官說因為MyISAM是表鎖，所以查詢快……
查閱相關資料，
讀：MyISAM 默認會把索引讀入內存，直接在內存中操作；InnoDB 則是 I/O 操作。（參考stackoverflow，具體url忘記了）

寫：MyISAM 是表鎖；InnoDB 是行鎖。
請各位大牛給予講解。

不存在這麼簡單的對比，如果這樣，直接把要多讀的表用MYISAM，要多寫的表用InnoDB好了。

要考慮許多因素，我列舉幾條：

1、如果都可以緩存數據在內存中，速度不會有大的差異，此時獲取數據的速度更決定於物理硬體的限制；

2、訪問模式對訪問速度有關係，如果並發高，表鎖的表現一般比行鎖差，因為你要處理並發衝突；

3、大部分小公司，或者早期的公司，用的是簡單的MYISAM，他們對於性能的要求本來就不高，表的數據比較少，MYISAM此時「顯得『很塊，如果數據量大了，公司發展了，業務邏輯關係複雜了。此時考驗資料庫的是緩存的設計，優化器的設計，一個這麼簡單的MYISAM引擎，怎麼可能快得過InnoDB呢。MYISAM是藉助操作系統來緩存數據的，操作系統是不知道優化資料庫訪問的，而InnoDB是用自己的緩存功能來加速訪問的，要知道優化越靠近應用/數據側才越有效果。

自己做一次帶源碼的性能分析不就明白了。別人說的可能有錯誤，自己去做反而還能增進技術。

比如以前MongD逼說自己性能無敵，通過做了一次，定位到了關鍵代碼段後，尼瑪這是性能高？這是來不及處理直接丟掉待處理數據性能當然高啊。

InnoDB在128核的機器可以跑到百萬 QPS~~然後竟然有人說 InnoDB 讀慢~~那得是十年前的事情了

MyISAM引擎設計簡單，數據以緊密格式存儲，所以某些讀取場景下性能很好。

但是MyISAM最典型的還是表鎖問題，這樣會導致長期處於"Locked"狀態。而且數據恢復時間長，無事務等問題或短板。

雖然5.1之前MyISAM的讀比Innodb快很多，但是在5.1之後，默認引擎已經變為Innodb。

Innodb讀寫有很大的提高，採用MVCC來支持高並發，針對行加鎖，是使用最廣泛的存儲引擎。

官方建議盡量將MyISAM都換為Innodb。

不要用MyISAM！

鎖粒度大只是一個小問題，關鍵是它會時不時莫名其妙地表損壞，修復也不是100%就能修成功。而且這玩意已經被官方放棄多年了，所有新的代碼都是基於InnoDB的，遇到點Bug就得跪。

剛才網上剛看到，如侵刪

......在執行資料庫寫入的操作（insert,update,delete）的時候，mysiam表會鎖表，而innodb表會鎖行。通俗點說，就是你執行了一個update語句，那麼mysiam表會將整個表都鎖住，其他的insert和delete、update都會被拒之門外，等到這個update語句執行完成後才會被依次執行。
而鎖行，就是說，你執行update語句是，只會將這一條記錄進行鎖定，只有針對這條記錄的其他寫入、更新操作會被阻塞並等待這條update語句執行完畢後再執行，針對其他記錄的寫入操作不會有影響。

而MyISAM本來速度就比較快

白話講MyIsam和InnoDB的區別

題目本身就是錯誤的，讀寫速度快慢和是否緩存沒有直接關係，只和每次讀寫的數據塊大小有關係。簡單點說，還是空間換時間。

關鍵是表級鎖這種設計太簡單粗暴了，現在主流資料庫一般不會鎖表，也不會鎖升級（行級鎖-&>表級鎖）。

innodb的緩衝池大小合適的話，單讀取，誰快誰慢還是一說呢

myism索引跟數據分開放，因此有讀取更快的說法。

innodb是行鎖，myism是鎖表，因此有innodb寫更快的說法。

但是以上說法要看應用場景，否則適得其反。在更新少，讀取多的應用中，myism更快，雖然是表鎖，但鎖的時候少，利用索引分開優勢，可以讀入內存，快速查詢。但是如果更新頻繁，經常鎖表，讀取性能會極速下降。

innodb適合更新頻繁的場景，否則更新效率也不如myism。innodb索引數據混在一個文件，建立索引比myism複雜，在更新不頻繁的應用場景中，myism更快

具體url忘了題主給個搜索詞或方向啊公司表全部都是myisam 磁碟io Mb以下我全部換了 innodb後 io kb - 幾百兆的蹦，老闆說這樣對磁碟不好。。。元旦放假了我懶得加班，直接全部改回去了，現在好奇，為什麼換成innodb後磁碟io變這麼大了，對了，大部分都是讀 io