如果主键页是碎片化的，全表扫描将会变得极其缓慢。图1阐释了这个问题。在InnoDB读取叶子页#3之后，它需要读取页#5230，在那之后还要读页#4。页#5230位置离页#3和页#4很远，所以磁盘读操作顺序开始变得几乎是随机的，而不是连续的。大家都知道HDD上的随机读要比连续读慢得多。一个有效的改进随机读性能的办法是使用SSD。不过SSD每个GB的价钱要比HDD昂贵的多，所以使用SSD通常是不可能的。
图 1.全表扫描实际没有连续读
线性预读取真的有意义吗？
InnoDB支持预读取特性，称作“线性预读取”（ Linear Read Ahead）。拥有线性预读取，如果N个page可以顺序访问（N可以通过innodb_read_ahead_threshold参数进行配置，默认为56），InnoDB可以一次读取一个extent(64个连续的page，如果不压缩每个page为1MB）。但是，实际来说这么做的意义不大。一个extent(64个page)非常小。对于一个支离破碎的较大的数据库表来说，下一个page不一定在同一个extent当中。上面图1就是一个很好的例子。读取page#3之后，InnoDB需要读取page#5230。page#3和page#5230并不在同一个extent当中，所以线性预读取技术在这里用处不大。这对于大表来说是非常常见的情况，所以这也解释了线性预读取技术为什么不能有效改善全表扫描的性能。
物理预读取
正如上面描述的，全表扫描速度较慢的主要原因是InnoDB主要进行随机读取。为了加速全表扫描，需要使InnoDB进行顺序读取。我想到的第一个方法就是创建一个UDF（user defined function)顺序的读取ibd文件(InnoDB的数据文件）。UDF执行完成后，ibd文件的page应当保存在InnoDB的缓存池当中，所以在进行全表扫描时无需再进行随机读取。下面是一个示例用法：
| mysql> SELECT buf_warmup ("db1", "large_table"); /* loading into buf pool */ mysql> SELECT * FROM large_application_table; /* in-memory select */ |
buf_warmup() 是一个用户自定义函数，用来读取数据库“db1"的表”large_table"的整个ibd文件。该函数需要花费时间将ibd文件从硬盘读取，但因为是顺序读取的，所以比随机读取要快的多。在我的测试当中，比普通的线性预读取快差不多5倍左右。
这证明ibd文件的顺序读取能够有效的改善吞吐率，但也存在一些缺点：
如果table的大小超过InnoDB缓存池的大小，这种方法就不能工作 在全表扫描过程中，读取整个的ibd文件就意味着不但需要读取primary key page还需要读取二级索引page以及一些其他不需要的page，并将其保存在缓存池，尽管只有primary key page是实际需要的。如果拥有大量的二级索引，这种方法就不能有效的工作 应用需要做出一定的修改以便调用UDF
