大幅提升MySQL中InnoDB的全表扫描速度的方法

 在 InnoDB中更加快速的全表扫描
 一般来讲,大多数应用查询的时候都会用索引，查找很少的几行数据（主键查找或百行内的查询），但有时候我们需要全表查询。典型的全表扫描就是逻辑备份  (mysqldump) 和 online schema changes（ 注：在线上对大表 schema 的操作，也是 facebook 的一个开源项目） (SELECT ... INTO OUTFILE).

 在 Facebook我们用 mysqldump 来备份数据库. 正如你所知MySql提供两种备份方式，提供了物理备份和逻辑备份的命令和工具. 相对物理备份，逻辑备份有一定的优势，例如:

逻辑备份的主要缺点是数据库的完全备份和完全还原比物理的备份恢复慢得多。

缓慢的完全逻辑备份往往会导致问题.如果数据库中存在很多大小支离破碎的表，它可能需要很长的时间。在 脸书，我们面临 mysqldump 的性能问题，导致我们不能在合理的时间内对一些(基于HDD和Flashcache的)服务器完成完整逻辑备份。我们知道 InnoDB做全表扫描并不高效，因为 InnoDB 实际上并没有顺序读取,在大多情况下是在随机读取。这是一个已知多年的老问题了。我们的数据库存储容量一直在增长，缓慢的全表扫描问题给我们造成了严重的影响,因此,我们决定加强 InnoDB 做顺序读取的速度。最后我们的数据库攻坚工程师团队在InnoDB 中实现了"Logical Readahead"功能。应用"Logical readahead"，在通常生产工作负载下，我们全表扫描速比之从前度提高 9 ~ 10 倍。在超负荷生产中，全表扫描速度达到 15 ~ 20 倍的速度甚至更快。

全表扫描在大的、碎片化数据表上的问题
做全表扫描时,InnoDB 会按主键顺序扫描页面和行。这应用于所有的InnoDB 表，包括碎片化的表。如果主键页表没有碎片（存储主键和行的页表),全表扫描是相当快，因为读取顺序接近物理存储顺序。这是类似于读取文件的操作系统命令(dd/cat/etc) 像下面。
 

不幸的是，在许多情况下主要关键页表存在碎片。例如，如果您需要管理 user_id 和 object_id 映射，主键将会是(user_id,object_id)。插入排序与 user_id并不一致，那么新插入/更新往往导致页拆分。新的拆分页将被分配在远离当前页的位置。这意味着页面将会碎片化。