轉自:https://blog.csdn.net/bigtree_3721/article/details/73151028web
InnoDB引擎表的特色緩存
一、InnoDB引擎表是基於B+樹的索引組織表(IOT)性能
關於B+樹優化
(圖片來源於網上).net
B+ 樹的特色:orm
(1)全部關鍵字都出如今葉子結點的鏈表中(稠密索引),且鏈表中的關鍵字剛好是有序的;cdn
(2)不可能在非葉子結點命中;blog
(3)非葉子結點至關因而葉子結點的索引(稀疏索引),葉子結點至關因而存儲(關鍵字)數據的數據層;索引
二、若是咱們定義了主鍵(PRIMARY KEY),那麼InnoDB會選擇主鍵做爲彙集索引、若是沒有顯式定義主鍵,則InnoDB會選擇第一個不包含有NULL值的惟一索引做爲主鍵索引、若是也沒有這樣的惟一索引,則InnoDB會選擇內置6字節長的ROWID做爲隱含的彙集索引(ROWID隨着行記錄的寫入而主鍵遞增,這個ROWID不像ORACLE的ROWID那樣可引用,是隱含的)。圖片
三、數據記錄自己被存於主索引(一顆B+Tree)的葉子節點上。這就要求同一個葉子節點內(大小爲一個內存頁或磁盤頁)的各條數據記錄按主鍵順序存放,所以每當有一條新的記錄插入時,MySQL會根據其主鍵將其插入適當的節點和位置,若是頁面達到裝載因子(InnoDB默認爲15/16),則開闢一個新的頁(節點)
四、若是表使用自增主鍵,那麼每次插入新的記錄,記錄就會順序添加到當前索引節點的後續位置,當一頁寫滿,就會自動開闢一個新的頁
五、若是使用非自增主鍵(若是身份證號或學號等),因爲每次插入主鍵的值近似於隨機,所以每次新紀錄都要被插到現有索引頁得中間某個位置,此時MySQL不得不爲了將新記錄插到合適位置而移動數據,甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉,此時又要從磁盤上讀回來,這增長了不少開銷,同時頻繁的移動、分頁操做形成了大量的碎片,獲得了不夠緊湊的索引結構,後續不得不經過OPTIMIZE TABLE來重建表並優化填充頁面。
綜上總結,若是InnoDB表的數據寫入順序能和B+樹索引的葉子節點順序一致的話,這時候存取效率是最高的,也就是下面這幾種狀況的存取效率最高:
一、使用自增列(INT/BIGINT類型)作主鍵,這時候寫入順序是自增的,和B+數葉子節點分裂順序一致;
二、該表不指定自增列作主鍵,同時也沒有能夠被選爲主鍵的惟一索引(上面的條件),這時候InnoDB會選擇內置的ROWID做爲主鍵,寫入順序和ROWID增加順序一致;
除此之外,若是一個InnoDB表又沒有顯示主鍵,又有能夠被選擇爲主鍵的惟一索引,但該惟一索引可能不是遞增關係時(例如字符串、UUID、多字段聯合惟一索引的狀況),該表的存取效率就會比較差。
《高性能MySQL》中的原話
歡迎關注