1.InnoDB與MyISAM區別：

InnoDB 支持事務，MyISAM 不支持事務。這是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一；

InnoDB 支持外鍵，而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉為 MYISAM 會失敗；

InnoDB 是聚集索引，MyISAM 是非聚集索引。

InnoDB 不保存表的具體行數，執行 select count(*) from table 時需要全表掃描。而MyISAM 用一個變量保存了整個表的行數，執行上述語句時只需要讀出該變量即可，速度很快；

InnoDB 最小的鎖粒度是行鎖，MyISAM 最小的鎖粒度是表鎖。一個更新語句會鎖住整張表，導致其他查詢和更新都會被阻塞，因此并發訪問受限。這也是 MySQL 將默認存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一；

(過時了)InnoDB不支持全文索引，而MyISAM支持全文索引，在涉及全文索引領域的查詢效率上MyISAM速度更快；PS：Mysql5.7及以后版本的InnoDB支持全文索引了。

注： innoDB的輔助索引是通過輔助索引找到主鍵，再通過該主鍵到主鍵索引找到數據。

如何選擇：

是否要支持事務，如果要請選擇 InnoDB ，如果不需要可以考慮 MyISAM；

如果表中絕大多數都只是讀查詢，可以考慮 MyISAM，如果既有讀也有寫也挺頻繁，請使用InnoDB；

系統奔潰后，MyISAM恢復起來更困難，能否接受，不能接受就選 InnoDB；

MySQL5.5版本開始Innodb已經成為Mysql的默認引擎(之前是MyISAM)，說明其優勢是有目共睹的。如果你不知道用什么存儲引擎，那就用InnoDB，至少不會差。

2.mysql 聚集索引和主鍵索引總結：

我們先了解下InnoDB引擎表的一些關鍵特征：InnoDB引擎表是基于B+樹的索引組織表(IOT)。

每個表都需要有一個聚集索引(clustered index)；所有的行記錄都存儲在B+tree的葉子節點(leaf pages of the tree)；

基于聚集索引的增、刪、改、查的效率相對是最高的；

如果我們定義了主鍵(PRIMARY KEY)，那么InnoDB會選擇其作為聚集索引；

如果沒有顯式定義主鍵，則InnoDB會選擇第一個不包含有NULL值的唯一索引作為主鍵索引；

如果也沒有這樣的唯一索引，則InnoDB會選擇內置6字節長的ROWID作為隱含的聚集索引(ROWID隨著行記錄的寫入而主鍵遞增，這個ROWID不像ORACLE的ROWID那樣可引用，是隱含的)。

綜上總結，如果InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致的話，這時候存取效率是最高的，也就是下面這幾種情況的存取效率最高：

使用自增列(INT/BIGINT類型)做主鍵，這時候寫入順序是自增的，和B+數葉子節點分裂順序一致；

如果該表不指定自增列做主鍵，同時也沒有可以被選為主鍵的唯一索引(上面的條件)，這時候InnoDB會選擇內置的ROWID作為主鍵，寫入順序和ROWID增長順序一致；

如果一個InnoDB表又沒有顯示主鍵，又有可以被選擇為主鍵的唯一索引，但該唯一索引可能不是遞增關系時(例如字符串、UUID、多字段聯合唯一索引的情況)，該表的存取效率就會比較差。

2.1 聚集索引 和 非聚集索引

聚集索引：將數據存儲與索引放在一塊，找到索引也就找到了數據。聚集索引表中存儲的數據按照索引的順序存儲，檢索效率比非聚集索引高，但對數據更新影響較大。(比如主鍵索引)

非聚集索引：將數據存儲與索引分開。MyISAM通過key_buffer把索引先緩存在內存中，訪問數據時，在內存中直接搜索索引，然后通過索引找到磁盤對應數據。 非聚集索引表示數據存儲在一個地方，索引存儲在另一個地方，索引帶有指針指向行數據的存儲位置。非聚集索引檢索效率比聚集索引低，但對數據更新影響較小。

每個InnoDB表都有一個稱為聚集索引的特殊索引，其中存儲了行的數據。通常，聚集索引與主鍵索引同義。

mysql的innodb表，就是索引組織表，表中的所有數據行都放在索引上，這就約定了數據是嚴格按照順序存放的，

聚集索引：葉子節點存的是整行數據，直接通過這個聚集索引的鍵值找到某行數據。

聚集索引：數據的物理存放順序與索引順序是一致的，即：只要索引是相鄰的，那么對應的數據一定也是相鄰地存放在磁盤上的。

聚集索引：數據行和相鄰的鍵值緊湊地存儲在一起，因為無法同時把數據行存放在兩個不同的地方，所以一個表只能有一個聚集索引。

mysql的innodb表，其聚集索引相當于整張表，而整張表也是聚集索引。默認通過主鍵聚集數據，如果沒有定義主鍵，則選擇第一個非空的唯一索引，如果沒有非空唯一索引，則選擇rowid來作為聚集索引

mysql的innodb表，因為整張表也是聚集索引，select出來的結果是順序排序的，比如主鍵字段的數據插入順序可以是5、3、4、2、1,查詢時不帶order by得出的結果也是按1、2、3、4、5排序。

2.2 基于主鍵索引和非主鍵索引(二級索引或普通索引)的查詢有什么區別？

主鍵索引的葉子節點存的是整行數據。在 InnoDB 里，主鍵索引也被稱為聚集索引(clustered index)。非主鍵索引的葉子節點內容是主鍵的值。在 InnoDB 里，非主鍵索引也被稱為二級索引(secondary index)。

如果語句是 select * from T where ID=500，即 主鍵查詢方式，則只需要搜索 ID 這棵 B+樹 ；

如果語句是 select * from T where k=5， 即 普通索引查詢方式，則需要先搜索 k 索引樹，得到 ID的值為 500，再到 ID 索引樹搜索一次。這個過程稱為回表。B+樹為了維護索引有序性，在插入新值的時候需要做必要的維護。以上面為例，

如果插入新的行 ID 值為 700，則只只需要在 R5 的記錄后面插入一個新記錄。

如果新插入的 ID值為 400，就相對麻煩了，需要邏輯上挪動后面的數據，空出位置。

3. 什么是最左前綴原則?

最左前綴匹配原則：在MySQL建立聯合索引時會遵守最左前綴匹配原則，即最左優先，在檢索數據時從聯合索引的最左邊開始匹配。

由于在B+樹結構的索引中，索引項是按照索引定義里面出現的字段順序排序的，索引在查找的時候，可以快速定位到 ID 為 100的張一，然后直接向右遍歷所有張開頭的人，直到條件不滿足為止。也就是說，當找到第一個滿足條件的人之后，直接向右遍歷就可以了，由于索引是有序的，所有滿足條件的人都會聚集在一起。而這種定位到最左邊，然后向右遍歷尋找的方式，就是我們所說的最左前綴原則。

示例：一個(a,b,c)的組合索引。

通過a,c條件查詢能不能使用或命中這個索引？-----能

通過b,c條件查詢能不能使用或命中這個索引？-----不能

原因：索引文件具有B-Tree 的最左前綴匹配特性，如果左邊的值未確定，那么無法使用此索引。

4.為什么用 B+ 樹做索引而不用哈希表做索引?

哈希表是把索引字段映射成對應的哈希碼然后再存放在對應的位置，這樣的話，如果我們要進行模糊查找的話，顯然哈希表這種結構是不支持的，只能遍歷這個表。而B+樹則可以通過最左前綴原則快速找到對應的數據。

如果我們要進行范圍查找，例如查找ID為100 ~ 400的人，哈希表同樣不支持，只能遍歷全表。

索引字段通過哈希映射成哈希碼，如果很多字段都剛好映射到相同值的哈希碼的話，那么形成的索引結構將會是一條很長的鏈表，這樣的話，查找的時間就會大大增加。

5.為什么建議使用主鍵自增的索引？

對于這棵主鍵索引的樹：

如果插入 ID = 650 的一行數據，那么直接在最右邊插入就可以了

但是如果插入的是 ID = 350 的一行數據，由于 B+ 樹是有序的，那么需要將下面的葉子節點進行移動，騰出位置來插入 ID = 350 的數據，這樣就會比較消耗時間。如果剛好 R4 所在的數據頁已經滿了，需要進行頁分裂操作，這樣會更加糟糕。

但是，如果主鍵是自增的，每次插入的 ID 都會比前面的大，那么每次只需要在后面插入就行， 不需要移動位置、頁分裂等操作，這樣可以提高性能。也就是為什么建議使用主鍵自增的索引。

總結

以上是生活随笔為你收集整理的mysql所有知识点总结_MySQL知识点总结的全部內容，希望文章能夠幫你解決所遇到的問題。

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