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