FAST TRAVERSE BLOCK(FTB)

    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结构，这也是个开销。