索引优化与设计(1)-引言

发表于 | 更新于 | 分类于 | 评论数：

本系列根据Relational Database Index Design and the Optimizers而写的读书笔记，这是第一篇，主要针对的是第一章。第一章主要介绍了传统的索引的设计的误区。随着磁盘的增大，磁盘访问时间的降低以及内存增大，以前用在索引设计上的“圣经”被证明是不对的，或是有缺陷的。本书从这一点出发，逐步讲述了索引设计以及优化的问题。

几个术语

第一章提到了几个术语，下面首先解释下以下几个术语。便于后面行文的理解。

buffer pool

这个是数据库中的概念，笔者参考了InnoDB[1]以及IBM DB2[2]概念和MySql技术内幕[3],buffer pool就是临时存放一些数据库page的内存区域。

InnoDB存储引擎是基于磁盘的，并且将其中的记录按照页(page)的方式进行管理。因此可以将其视为磁盘的数据库系统(Disk-base Database)。在数据库系统中，由于CPU的速度和磁盘速度之间的鸿沟，基于磁盘的数据库系统通常使用缓冲池技术来提高数据库的整体性能。

缓冲池简单来说就是一块内存区域，通过内存的速度来弥补磁盘的速度较慢对数据库的影响。在数据库中进行页的操作的时候，首先将从磁盘读到的页放到缓冲池中，这个过程称为将页“FIX”在缓冲池中。下一次再次读取的时候，首先判断该页是否在缓冲池中。若在缓冲池中，称为该页在缓冲池中命中，直接读取该页。否则，读取磁盘上的页。

InnoDB默认buffer pool的大小是128M[4]，可以存放好几百的page，甚至可以达到GB，这个值可以调节。

disk cache

同样的，也是用RAM来存放部分磁盘数据的一部分区域[5]。这个RAM可以存在于磁盘上(这也称为hard disk cache or buffer)[6]，或者是普通的内存的RAM(这也称为soft disk cache)。hard disk cache更加的有效，因为直接是在磁盘上的一小部分区域，但是更贵，所以，会相对来说比较小。几乎所有的HDD都会有一部分很小的hard disk cache(8-256MB)，SSD的可能达到1GB[6]。

disk cache的作用也是将一些从磁盘读取的数据先存到disk cache中，避免了再次去disk读取耗费很长的时间。作用和原理跟buffer pool一样的。

那么问题来了，buffer pool和disk cache既然作用都是相同的，那么他们的区别在哪儿呢？这个问题找了很多的资料，还是没看懂，所以，这个后面有时间在详细研究。

笔者先尝试着解答上面的问题，参考了以下资料[7,8],个人认为这里面的buffer pool是数据库的概念。而disk cache是文件系统的概念。但是作用都是一样的，所以是没有差别的。但是假设都是操作系统的概念的话，那么就有差别了。差别就是文献7,8里面讲的。

几个索引的误区

第一章主要分析了几个以前索引设计的误区，例如，index层数(主要针对B-Tree来说的)最好不要超过5层，但是作者通过分析，如果把非叶子节点存放到磁盘中，那么只要访问非叶子节点，都会造成磁盘IO(10ms，这个请参考Jeff Dean的一些数据，本文给贴出来了，图1),所以索引的层数并不是很重要。还有一个就是每个表中最好不要多余6个索引列。以及不要在列值经常变化的列上面建立索引等。这些都被后面的例子证明是错误的。
number-should-know

总结

第一章主要给出了一些引言，本文主要着重分析了几个术语便于以后的理解。至于索引的优化细节，本文会继续跟随着作者章节的脚步慢慢深入分析。

参考文献