MySQL 中 MyISAM 中的查詢為什麼比 InnoDB 快？

點選上方“業餘草”，選擇“置頂公眾號”

第一時間獲取技術乾貨和業界資訊！

 

 

哎呀，一年之計在於春啊。最近過完年了，微信群裡有非常多的小夥伴在問我一下面試方面的問題。比如：有讓我出題的，有讓我推薦資料的，還有讓我推薦公司的。。。

真是太難為我了！也有些人剛開過年，任務不算多。所以，經常醬油，不知道該學習什麼？

於是，我發了一套面試題，如下：

結果，他們都來要答案了。哎，做伸手黨可不好，什麼時候才能獨立呢？所以，我一一的拒絕了他們。

關於這套面試題，有很多內容，我都寫過文章的！今天，我們來寫一寫第 14 小題。為什麼 MyisAM 查詢快？

關於，這個問題，我網上看了很多答案。大多內容都雷同，但是我要強調的是，並不是說 MYISAM 一定比 InnoDB 的 select 快。

其實呢？MyISAM 適合讀多，併發少的場景；這個問題要分場景來看。不同的場景，還真不能說 MyISAM 比 InnoDB 中的查詢快！

下面我們一起來看看 Innodb 和 Myisam 的 5 大區別：

上面的“事務”寫錯了。不過，我相信大家能看明白其中的解釋。

關於“行鎖”還是“表鎖”，可以看我的這篇文章《InnoDB 的 select 行鎖還是表鎖》。

關於 count 的區別，可以看我的這篇文章《你真的懂 select count(*) 嗎？》。

那麼為什麼大家喜歡說 MyisAM 查詢快呢？那是因為，InnoDB 的表是根據主鍵進行展開的 B+tree 的聚集索引。MyIsam 則非聚集型索引，myisam 儲存會有兩個檔案，一個是索引檔案，另外一個是資料檔案，其中索引檔案中的索引指向資料檔案中的表資料。

聚集型索引並不是一種單獨的索引型別，而是一種儲存方式，InnoDB 聚集型索引實際上是在同一結構中儲存了 B+tree 索引和資料行。當有聚簇索引時，它的索引實際放在葉子頁中。

結合上圖，可以看出：INNODB 在做 SELECT 的時候，要維護的東西比 MYISAM 引擎多很多。

InnoDB：通過為每一行記錄新增兩個額外的隱藏的值來實現 MVCC，這兩個值一個記錄這行資料何時被建立，另外一個記錄這行資料何時過期（或者被刪除）。但是 InnoDB 並不儲存這些事件發生時的實際時間，相反它只儲存這些事件發生時的系統版本號。這是一個隨著事務的建立而不斷增長的數字。每個事務在事務開始時會記錄它自己的系統版本號。每個查詢必須去檢查每行資料的版本號與事務的版本號是否相同。讓我們來看看當隔離級別是 REPEATABLEREAD 時這種策略是如何應用到特定的操作的：

SELECT InnoDB 必須每行資料來保證它符合兩個條件：

說白了，為什麼現在一些人喜歡 NoSQL 呢？因為 nosql 本身似乎應該是以省去解析和事務鎖的方式來提升效能。MYISAM 不支援事務，也是它查詢快的一個原因！

原文連結：MySQL 中 MyISAM 中的查詢為什麼比 InnoDB 快？

10T技術資源大放送！包括但不限於：C/C++，Linux，Python，Java，PHP，人工智慧，GO等等。在公眾號內回覆對應關鍵字或框架名字，即可免費獲取！！

 你再主動一點點   我們就有故事了