INDEX是一個B樹結構，在訪問index entry的時候，要從root page開始，折半找到non-leaf page,最後逐漸遍歷至leaf page,leaf page上存了所有的index entry(key+RID),再根據RID找到對應的data record。過程如下圖
這樣看來，如果index level夠大，爲了拿到leaf page,就要拿到更多的non-leaf page,而這些non-leaf page上有沒有存真是的index entry,如果buffer足夠大，這倒沒什麼，無非就是儘可能在buffer裏面多放non-leaf page就可以了。可是如果buffer pool不夠大，那麼勢必會增加I/O的成本，從而影響data的訪問效率。那麼有沒有好的辦法可以儘快的遍歷到leaf page,從而更快的找到data record呢？當然是有的，在DB2 V12裏，增加了一個FTB的新功能，能夠幫助我們快速的定位到leaf page,下圖直觀的說明了FTB的遍歷機制。
把non-leaf page搞在一起作爲child non-leaf block,裏面有指針指向child leaf node, child leaf node裏有{index key, leaf page number},這樣就不用拿那麼多無效的non-leaf page,可以直接通過FTB的結構定位到leaf page,再從過leaf page裏的RID定位到data record。下圖是FTB的內部結構示意圖：
那如何使用這項功能呢？
首先，系統層面上由ZPARM INDEX_MEMORY_CONTROL控制，這是一個可以在線改的系統參數，具體的用法可以參考IBM官方文檔。其次，也可以由user指定哪些index在何時可以具備這項功能，用戶可以在SYSIBM.SYSINDEXCONTROL裏插入一些record加以說明，具體的用法也可以參考IBM官方文檔。
Db2會啓動後臺進程014.IFTOMK**，爲合適的index建一個FTB,並且在index結構發生變化的時候，也及時的update FTB的結構，這樣在traverse的時候，通過FTB traverse到leaf page。
這樣做的好處，是查詢快了，但是對於需要頻繁update的index來說，需要DB2同時維護好本來的index B數結構，又要維護好FTB結構，這也是個開銷。