百度了一遍下來都在說myisam引擎的查詢性能比innodb好，但是沒有看到拿數據出來說話的，今天得空就做了下測試。

知識回顧

摘抄自：https://blog.csdn.net/STFPHP/article/details/52827845?utm_source=blogkpcl13

MyISAM索引的實現

MyISAM索引文件和數據文件是分離的，索引文件僅保存記錄所在頁的指針(物理位置)，通過這些地址來讀取頁，進而讀取被索引的行。下圖是MyISAM的索引原理圖：(為了簡化，一個頁內只存放了兩條記錄。)

上圖所提供的示例表字段有Col1(ID)、Col2(age)、Col3(name)三個，其中Col1為Primary Key(主鍵)，上圖很好地說明了樹中葉子保存的是對應行的物理位置。通過該值，存儲引擎能順利地進行回表查詢，得到一行完整記錄。同時，每個葉子頁也保存了指向下一個葉子頁的指針。從而方便葉子節點的范圍遍歷。

而對于二級索引，在 MyISAM存儲引擎中以與上圖同樣的方式實現，這也說明了 MyISAM的索引方式是“非聚集的”，與 Innodb的“聚集索引”形成了對比。

InnoDB索引的實現

聚集索引

與 MyISAM相同的一點是，InnoDB 也采用 B+Tree這種數據結構來實現 B-Tree索引。而很大的區別在于，InnoDB 存儲引擎采用“聚集索引”的數據存儲方式實現B-Tree索引，所謂“聚集”，就是指數據行和相鄰的鍵值緊湊地存儲在一起，注意 InnoDB 只能聚集一個葉子頁(16K)的記錄(即聚集索引滿足一定的范圍的記錄)，因此包含相鄰鍵值的記錄可能會相距甚遠。

在 InnoDB 中，表被稱為 索引組織表(index organized table)，InnoDB 按照主鍵構造一顆 B+Tree (如果沒有主鍵，則會選擇一個唯一的并且非空索引替代，如果沒有這樣的索引，InnoDB則會隱式地定義一個主鍵來作為聚集索引)，同時葉子頁中存放整張表的行記錄數據，也可以將聚集索引的葉子節點稱為數據頁，非葉子頁可以看做是葉子頁的稀疏索引。

下圖說明了 InnoDB聚集索引的實現方式，同時也體現了一張 innoDB表的結構，可以看到，InnoDB 中，主鍵索引和數據是一體的，沒有分開。：

這種實現方式，給予了 InnoDB 按主鍵檢索的超高性能。可以有目的性地選擇聚集索引，比如一個郵件表，可以選擇用戶ID來聚集數據，這樣只需要從磁盤讀取較少并且連續的數據頁就能獲得某個id的用戶全部的郵件，避免了讀取分散頁時所耗費的隨機I/O。

輔助索引

而對于輔助索引，InnoDB采用的方式是在葉子頁中保存主鍵值，通過這個主鍵值來回表(上圖)查詢到一條完整記錄，因此按輔助索引檢索實際上進行了二次查詢，效率肯定是沒有按照主鍵檢索高的。下圖是輔助索引的實現方式：

由于每個輔助索引都包含主鍵索引，因此，為了減小輔助索引所占空間，我們通常希望 InnoDB 表中的主鍵索引盡量定義得小一些(值得一提的是，MySIAM會使用前綴壓縮技術使得索引變小，而InnoDB按照原數據格式進行存儲。)，并且希望InnoDB的主鍵是自增長的，因為如果主鍵并非自增長，插入時，由于寫入時亂序的，會使得插入效率變低。

最后，我們要知道，B-Tree索引適用于等值匹配、范圍匹配、鍵前綴匹配，這里的前綴指的是最左前綴。

測試

分別建立相同字段、索引列相同的倆長表，一個引擎是myisam, 一個是innodb

創建隨機生成字符串和數字的函數，用于數據插入

3. 創建批量插入數據的函數

測試準備工作完成，開始

數據量在1w時，索引查詢和非索引查詢區別不大(紅色箭頭處為查詢時間 單位秒)

數據量10W 索引查詢區別不大， 非索引字段查詢myisam要快些

數據量100w時 非索引字段查詢myisam引擎的優勢彰顯出來了

數據量500w時 非索引字段查詢myisam引擎的優勢彰顯出來了

索引查詢倆個引擎差不多，但是非索引查詢差別就很明顯了，innodb耗時10s以上，而myisam只有0.6s

總結

MYIASM和INNODB查詢使用索引時性能相差無幾

但全表掃描時MYIASM查找的性能要好很多

標簽：聚集,查詢,索引,innode,InnoDB,myisam,mysql,主鍵

來源： https://blog.csdn.net/qq_35623773/article/details/114682703

總結

以上是生活随笔為你收集整理的mysql 查询效率测试,mysql innode和myisam引擎查询性能比较测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。