E-R圖也稱實體-聯繫圖(Entity Relationship Diagram)，它提供了表示實體類型、屬性和聯繫的方法，用來描述現實世界的概念模型。 ...
先大體看一下MySQL的SQL layer層的一個架構流程：
對一些關鍵模塊做一下簡單的描述:
1. 初始模塊：初始一些參數，比如初始myinit配置文件（在安裝的根目錄下）里的一些參數。
2. 連接管理模塊：啟動監聽，監聽連接請求
3. 連接進程模塊：可以理解為線程池
4. 用戶模塊：檢驗用戶，令牌和許可權
5. 命令分發器：處理不同類型的請求
6. 查詢緩存模塊：做緩存處理，做查詢的cache,可以理解為一個Map，查詢語句為key，結果值為value
7. 日誌記錄模塊
8. 命令解析器（parser）：對於不同類型的sql語句進行處理分發，select：查詢優化器，dml：表變更模塊，ddl：表維護模塊，rep：複製模塊（主從複製），status：狀態模塊。
9. 訪問控制：
10. 表管理模塊：
11. 存儲引擎介面：和Storage Engines打交道
直接來到Storage Engines，這講的最多的就是引擎了，如：
Myisam、Innodb、Faicon、Memory、Archive等等引擎
而我們常用的是Innodb和Myisam這兩種，這兩種索引最直接的區別，可以從採用對應引擎而生成的數據表文件，進行對比。比如：採用Innodb引擎生成表A，採用Myisam索引生成表B。
現在可以從Mysql安裝目錄/data/資料庫名 ，這個目錄下看到有5個文件：
A.frm : 表定義文件
A.ibd ：數據和索引都存儲在這個文件
B.frm ：表定義文件
B.myd ：數據文件
B.myi ：索引文件
顯然，兩者從文件上體驗出來的區別就是，Myisam是把數據和索引分開存儲在兩個不同的文件里。（那其本質里的區別是什麼？急啥）
且看，衡量一個索引的標準是什麼？
就是，IO漸進複雜度，翻譯成人話就是：當數據越來越多的時候，索引是否依然高效，即查詢依然那麼快。
一個索引是否高效在某種程度上取決於其採用的索引結構。
Hash索引：
對索引欄位做Hash計算，落到不同槽裡面，有個明顯的缺點是，無法做範圍查詢，例如 select * from data where id >1
Fulltext索引：
全文搜索索引，比如欄位的值是：abcdefghijk，它就會再生成一列abcde* ,用於首碼的模糊全文搜索。
R-Tree索引：
引用的場景主要是 空間索引，比如說，美團上訂電影票，就可以選擇3km範圍內的影院，結果就搜出來了。
B-Tree索引：
這個索引就是我要重點講的索引，因為Innodb和Myisam採用的是B+ Tree 索引，而B+ Tree是從B-Tree基礎上演變而來。
那B-Tree是怎麼樣的呢？如圖：
每個節點上有一個索引（上方的數字，id的值），和索引對應的數據（下方藍色：id, name）
而B+Tree：
上方白色的數字都為索引的key，而data全放在下麵。（居於此結構，如果想知道它是怎麼根據key從上到下找到對應的data的，我提供一個非常好玩的web工具，去玩一下琢磨一下。https://www.cs.usfca.edu/~galles/visualization/Algorithms.html）
雖然Innodb和Myisam都是採用B+Tree索引，但是它們是有區別的，如圖：
前面已經說了，Myisam引擎方式的，會把索引和數據分開存儲在兩個文件中，一個文件負責數據的插入、更新等，另一個負責索引的維護。如圖，索引中白色的key為索引的值，下麵淺綠色為data：對應數據的地址。如果多個索引就，就多個這種模式，如圖，以name為索引，也是一樣。
而Innodb:如圖：
上面也提到，Innodb是把數據和索引都放在同一個文件里的，那索引和數據共存的形式是：如圖，白色中的為key，即使索引，當從上到下找到對應的key之後，key下麵存放的就是整條對應的數據了，而不是想Myisam那樣存放的是數據對應的地址了。
那麼問題來了，Innodb多個索引的話，是一種什麼樣的存在呢，還是如上圖右方，增加欄位name為索引：它就會建立一個副索引樹，同樣的結構，白色key索引存放的是name欄位對應的值，而藍色方的data存放的是主索引樹的key。
舉個例子，當id和name都作為索引的時候，執行select * from table where name = ‘james’ ，
第一步會先在副索引找到key為james的data為1，1是主索引的key。
第二步再到主索引找到key為對1的數據。（select * from table where id= 1）
多提一句，像這種索引的方式叫“聚集索引”，理解為key和data都綁定在一起了。
而Myisam的那種索引的方式叫做“非聚集索引”。
對於B+Tree這種索引，討論一下uuid和自增id。
Uuid是32位的，毋庸置疑，相對於自增id，uuid的存儲空間是較大的。而且uuid為索引時，其要進行較複雜的運算，最終確定索引的key要插入到哪個位置。
而自增id，它符合每次加1的規則，而且規矩已經確定了，它不要做過多的運算，直接從左到右進行橫向的擴展（插入），這樣性能就有了差別，如圖（B+Tree樹的高度是固定的，為4層）：
即使是這樣，uuid依然在一些項目依然有它市場：
自增id雖然有多個優點，但實際大型項目中卻很少採用自增長id的，這是為什麼呢？因為uuid幾乎保證了不同資料庫的不同表的id唯一，可以進行數據切分合併，而自增長id只能保證一個資料庫中的一張表的id唯一，進行資料庫合併的話並然會因主鍵衝突而失敗，這是一個硬傷。
而且有博主說：分散式架構，意味著需要多個實例中保持一個表的主鍵的唯一性。這個時候普通的單表自增ID主鍵就不太合適，因為多個mysql實例上會遇到主鍵全局唯一性問題
再談談組合索引的一些小問題
組合索引是有順序的，叫做最左原則。什麼意思呢。舉個例子：
name、age、weight 這3個欄位組成組合索引，name排在第1位，那麼查詢語句where 後面必須要有name=”value”這個條件，否則此索引是不起作用的，這叫最左原則。
再引用網上的一個例子：
索引的好處就是：
1. 提高檢索效率
2. 降低排序成本，索引對應的欄位是會有一個自動排序功能的，預設是升序asc。
Every coin has two sides，它缺點是
1. 更新索引的IO量。
就是說，當插入一條數據的時候，除了插入數據的本身，還要插入該數據對應索引信息的節點，如果對應的表是多個索引的，就插入多個數據對應的索引信息節點。而且這些都是以文件類型存儲在硬碟上的。
2. 調整索引所致的計算量，
這個又是怎麼理解呢，舉個例子，像B-tree索引，在插入索引之前，都要進行計算，該索引要申請多少的空間，插入到哪個位置。
3. 占用存儲空間。
竟然索引有壞有好，什麼時候需要索引，什麼時候不需要？
適合：
1. 較頻繁的作為查詢條件的欄位應該創建索引
不適合：
1. 欄位值的唯一性太差不適合單獨做索引
2. 更新非常頻繁的欄位不是
3. 不會出現在where句中的欄位不適合。
