各位有夢想的阿猿大家好，我是初昕之旅，您技術成長之路上的好幫手。今天繼續更新《來道題》系列，每天一道面試題，年薪百萬來找你~
InnoDB的特性
InnoDB存儲引擎作為MySQL資料庫的預設存儲引擎，在衆多公司中都有着極其廣泛的應用率，凡是考察到關系型資料庫時，都繞不開InnoDB的相關特點。是以，InnoDB有哪些特性，是網際網路服務端面試的一道重點考題。有的同學可以能回答出來，比如InnoDB和MyISAM的差別是InnoDB能夠支援事務、支援外鍵等等，很不錯，這确實是InnoDB的一些特點，但這遠遠不夠，隻是及格的水準，面試時這種回答的程度通常是熱場級别的，面試官一般還會沿着這個問題繼續往下問，這個時候還有多少同學能繼續深挖答案呢？
今天我們就來講一下InnoDB的自适應哈希索引、插入緩沖、重新整理鄰接表、二次寫等四大特性。
自适應哈希索引
自适應哈希索引
我們都知道，InnoDB中最基本的索引是B+樹，每層非葉子節點僅存儲下一層節點的值範圍，直到葉子節點時才存儲真實的資料。通常情況下，B+樹對磁盤查詢路徑的穩定已經能支撐很大的吞吐量了，但對于存儲引擎來說，顯然會想要更進一步地優化性能，自适應哈希索引就誕生了。
自适應哈希索引的應用場景是，當我們有一些熱點頁的查詢，比如一些需要高頻使用的資料項，這類查詢可能會占我們所有的連結中很大的一部分，而這些查詢的條件又是固定，比如都是WHEREid=1。此時，InnoDB會将這些條件的語句存儲下來，建立一個符合等值查詢的哈希索引，當下次再有相同的查詢語句過來時，首先去判斷一下是否能夠命中哈希索引，如果可以，則直接跳轉到對應的資料頁中；否則，則按正常的B+樹，一層層地範圍比對，最後定位到資料頁中。那麼所謂自适應，也就是這種索引的建立是不需要我們應用層的研發來關注或變更的，它屬于存儲引擎内自身的優化手段。
插入緩沖
插入緩沖
在作業系統的相關知識中，我們能知道檔案是存在多級索引頁的分層的，通過索引可以更快速地定位到檔案内容。而我們資料庫中資料表的變更，最終會對應到機器上一些特定檔案的内容變更，每次的變更都會涉及通過索引頁來定位的過程。InnoDB針對上述過程中增加了一個緩沖機制，針對非聚簇索引中的插入和删除操作，注意這裡隻涉及非聚簇索引，沒有聚簇索引。同時，隻有插入和删除操作，不包含更新。針對這類操作，如果其中一些操作是都屬于同一個索引頁的，那麼這些操作會被合并起來，統一和檔案層進行互動，減少I/O的次數，進而提升性能。是以為了滿足這種合并，我們需要有索引頁的緩沖，并且在真正執行檔案層面的操作時，在緩沖池中進行操作的識别和分類，把相同索引頁的操作合并起來，一起執行。
重新整理鄰接頁
重新整理鄰接頁
髒頁是在記憶體中發生變更的資料，最終需要落盤到檔案中來永久生效，也就是髒頁的重新整理。同樣的，在InnoDB存儲引擎中，有一個緩沖池來管理。每一個資料頁都會有一個标記位，标記該頁自從上次重新整理後，是否有再次發生修改，如果有修改，則需要進行重新整理髒頁的動作。前面也提到了檔案的多級索引，在實體層面的位址空間中，檔案是有分區的，而一次重新整理會涉及I/O的操作，同樣是對性能有影響的。是以InnoDB在進行髒頁重新整理之前，會檢測一下是否有相同區的髒頁需要重新整理，如果有則合并到一個操作裡一起去進行，減少随機I/O，提升性能。
二次寫
二次寫
同樣也是發生在重新整理髒頁時，如果我們直接從資料頁寫入到檔案中，在此耗時中如果發生了一些機器故障之類的問題，會産生部分寫失效的問題。而這種問題通過redo_log等機制無法修複。是以InnoDB會在磁盤的共享表空間中開辟一塊區域。這次我們不直接寫檔案，首先我們先将需要重新整理的資料存儲到緩沖池中，通過緩沖池，我們優先寫剛才提到的共享表空間，之後再去寫磁盤，而在此過程中，如果還是發生了資料庫當機等，可以在共享表空間内找到部分寫失效的頁的副本，用redo_log進行資料恢複。
總結
那麼以上就是我們講解的InnoDB存儲引擎的四大特性，我們最後再來簡單回顧一下：
- 自适應哈希索引：根據熱點頁的連續查詢條件，建立适合等值查詢的哈希索引
- 插入緩沖：合并非唯一的非聚簇索引中同索引頁的插入/删除操作，提升性能
- 重新整理鄰接頁：相同位址的髒頁合并重新整理，減少随機I/O
- 二次寫：重新整理髒頁時複制到雙寫緩沖，寫共享表空間、磁盤，避免寫部分頁。
那麼等下次面試時，如果各位同學能夠回答出來以上的知識點，我相信面試官一定會對咱們刮目相看的，一看就是一個熱愛學習、有思考的好工程師。每天一道面試題，年薪百萬來找你~
附視訊講解：
視訊加載中...