儲存引擎

MySQL當前預設的儲存引擎是InnoDB,並且在5.7版本所有的儲存引擎中只有 InnoDB 是事務性儲存引擎，也就是說只有 InnoDB 支援事務。

MyISAM和InnoDB對比

InnoDB
InnoDB 是 MySQL 預設的事務型儲存引擎，只要在需要它不支援的特性時，才考慮使用其他儲存引擎。

InnoDB 採用 MVCC 來支援高併發，並且實現了四個標準隔離級別(未提交讀、提交讀、可重複讀、可序列化)。其預設級別時可重複讀（REPEATABLE READ），在可重複讀級別下，通過 MVCC + Next-Key Locking 防止幻讀。

主索引時聚簇索引，在索引中儲存了資料，從而避免直接讀取磁碟，因此對主鍵查詢有很高的效能。

InnoDB 內部做了很多優化，包括從磁碟讀取資料時採用的可預測性讀，能夠自動在記憶體中建立 hash 索引以加速讀操作的自適應雜湊索引，以及能夠加速插入操作的插入緩衝區等。

InnoDB 支援真正的線上熱備份，MySQL 其他的儲存引擎不支援線上熱備份，要獲取一致性檢視需要停止對所有表的寫入，而在讀寫混合的場景中，停止寫入可能也意味著停止讀取。

MyISAM
設計簡單，資料以緊密格式儲存。對於只讀資料，或者表比較小、可以容忍修復操作，則依然可以使用它。

提供了大量的特性，包括壓縮表、空間資料索引等。

不支援事務。

不支援行級鎖，只能對整張表加鎖，讀取時會對需要讀到的所有表加共享鎖，寫入時則對錶加排它鎖。但在表有讀取操作的同時，也可以往表中插入新的記錄，這被稱為併發插入（CONCURRENT INSERT）。

可以手工或者自動執行檢查和修復操作，但是和事務恢復以及崩潰恢復不同，可能導致一些資料丟失，而且修復操作是非常慢的。

如果指定了 DELAY_KEY_WRITE 選項，在每次修改執行完成時，不會立即將修改的索引資料寫入磁碟，而是會寫到記憶體中的鍵緩衝區，只有在清理鍵緩衝區或者關閉表的時候才會將對應的索引塊寫入磁碟。這種方式可以極大的提升寫入效能，但是在資料庫或者主機崩潰時會造成索引損壞，需要執行修復操作。
MyISAM是MySQL的預設資料庫引擎（5.5版之前）。雖然效能極佳，而且提供了大量的特性，包括全文索引、壓縮、空間函式等，但MyISAM不支援事務和行級鎖，而且最大的缺陷就是崩潰後無法安全恢復。不過，5.5版本之後，MySQL引入了InnoDB（事務性資料庫引擎），MySQL 5.5版本後預設的儲存引擎為InnoDB。

1.事務：InnoDB 是事務型的，可以使用 Commit 和 Rollback 語句。
2.併發：MyISAM 只支援表級鎖，而 InnoDB 還支援行級鎖。
3.外來鍵：InnoDB 支援外來鍵。
4.備份：InnoDB 支援線上熱備份。
5.崩潰恢復：MyISAM 崩潰後發生損壞的概率比 InnoDB 高很多，而且恢復的速度也更慢。
6.是否支援MVCC ：僅 InnoDB 支援。應對高併發事務, MVCC比單純的加鎖更高效;MVCC只在 READ COMMITTED 和 REPEATABLE READ 兩個隔離級別下工作;MVCC可以使用 樂觀(optimistic)鎖 和 悲觀(pessimistic)鎖來實現;各資料庫中MVCC實現並不統一。推薦閱讀： MySQL-InnoDB-MVCC多版本併發控制.
7.其它特性：MyISAM 支援壓縮表和空間資料索引。

字符集及校對規則

字符集指的是一種從二進位制編碼到某類字元符號的對映。校對規則則是指某種字符集下的排序規則。MySQL中每一種字符集都會對應一系列的校對規則。

MySQL採用的是類似繼承的方式指定字符集的預設值，每個資料庫以及每張資料表都有自己的預設值，他們逐層繼承。比如：某個庫中所有表的預設字符集將是該資料庫所指定的字符集（這些表在沒有指定字符集的情況下，才會採用預設字符集）
MySQL字符集及校對規則的理解：
https://www.cnblogs.com/geaozhang/p/6724393.html#MySQLyuzifuji

索引

聚簇索引和非聚簇索

聚簇索引和非聚簇索引詳解
https://blog.csdn.net/qq_38850577/article/details/110950076

雜湊索引

雜湊索引能以 O(1) 時間進行查詢，但是失去了有序性：

1.無法用於排序與分組。
2.只支援精確查詢，無法用於部分查詢和範圍查詢。

InnoDB 儲存引擎有一個特殊的功能叫“自適應雜湊索引”，當某個索引值被使用的非常頻繁時，會在 B+Tree 索引之上再建立一個雜湊索引，這樣就讓 B+Tree 索引具有雜湊索引的一些優點，比如快速的雜湊查詢。

全文索引

MyISAM 儲存引擎支援全文索引，用於查詢文字中的關鍵詞，而不是直接比較是否相等。

查詢條件使用 MATCH AGAINST，而不是普通的 WHERE。

全文索引使用倒排索引實現，它記錄著關鍵詞到其所在文件的對映。

InnoDB 儲存引擎在 MySQL 5.6.4 版本中也開始支援全文索引。

空間資料索引

MyISAM 儲存引擎支援空間資料索引（R-Tree），可以用於地理資料儲存。空間資料索引會從所有維度來索引資料，可以有效地使用任意維度來進行組合查詢。

必須使用 GIS 相關的函式來維護資料。

B + 樹與紅黑樹的比較

紅黑樹等平衡樹也可以用來實現索引，但是檔案系統及資料庫系統普遍採用 B+ Tree 作為索引結構，主要有以下兩個原因：

（一）磁碟 IO 次數

B+ 樹一個節點可以儲存多個元素，相對於紅黑樹的樹高更低，磁碟 IO 次數更少。

（二）磁碟預讀特性

為了減少磁碟 I/O 操作，磁碟往往不是嚴格按需讀取，而是每次都會預讀。預讀過程中，磁碟進行順序讀取，順序讀取不需要進行磁碟尋道。每次會讀取頁的整數倍。

作業系統一般將記憶體和磁碟分割成固定大小的塊，每一塊稱為一頁，記憶體與磁碟以頁為單位交換資料。資料庫系統將索引的一個節點的大小設定為頁的大小，使得一次 I/O 就能完全載入一個節點。

索引的優點

1.大大減少了伺服器需要掃描的資料行數。

2.幫助伺服器避免進行排序和分組，以及避免建立臨時表（B+Tree 索引是有序的，可以用於 ORDER BY 和 GROUP BY 操作。臨時表主要是在排序和分組過程中建立，不需要排序和分組，也就不需要建立臨時表）。

3.將隨機 I/O 變為順序 I/O（B+Tree 索引是有序的，會將相鄰的資料都儲存在一起）。

索引的使用條件

1.對於非常小的表、大部分情況下簡單的全表掃描比建立索引更高效；

2.對於中到大型的表，索引就非常有效；

3.但是對於特大型的表，建立和維護索引的代價將會隨之增長。這種情況下，需要用到一種技術可以直接區分出需要查詢的一組資料，而不是一條記錄一條記錄地匹配，例如可以使用分割槽技術。

為什麼對於非常小的表，大部分情況下簡單的全表掃描比建立索引更高效？

如果一個表比較小，那麼顯然直接遍歷表比走索引要快（因為需要回表）。

注：首先，要注意這個答案隱含的條件是查詢的資料不是索引的構成部分，否也不需要回表操作。其次，查詢條件也不是主鍵，否則可以直接從聚簇索引中拿到資料。

索引優化

MySQL索引優化
https://blog.csdn.net/qq_38850577/article/details/110952530

查詢效能優化

explain 用來分析 SELECT 查詢語句，開發人員可以通過分析 Explain 結果來優化查詢語句。

優化資料訪問

MySQl優化資料訪問

事務

MySql事務知識點總結

鎖

MySQL鎖知識點總結

分庫分表資料切分

美團的Leaf分散式ID生成系統 ：Leaf 是美團開源的分散式ID生成器，能保證全域性唯一性、趨勢遞增、單調遞增、資訊保安，裡面也提到了幾種分散式方案的對比，但也需要依賴關聯式資料庫、Zookeeper等中介軟體。感覺還不錯。美團技術團隊的一篇文章：https://tech.meituan.com/2017/04/21/mt-leaf.html 。

複製

MySQL複製知識點總結