Facebook对MySQL全表扫描性能的改进

原文博客如下：

http://yoshinorimatsunobu.blogspot.com/2013/10/making-full-table-scan-10x-faster-in.html

如下是读博客做的笔记：

Facebook对全表扫描的需求场景：

1.logical backups(eg: mysqldump);

2.online schema changes(eg: SELECT... INTO OUTFILE);

Facebook 使用logical backups(vs physical backup)的原因：

1.size is mush smaller(3x ~10 x);

2.eaier to parse backups;

drawbacks of logical backup:

full backup and full restore are much slower than physical backup/restore.

如果数据库大时，表一般都是fragmented，此时InnoDB的全表扫描是随机读而非顺序读。

Logical Readahead即为实现InnoDB全表扫描时的顺序读。

给出的性能提升数据：

1. 9~10 times faster under usual production workloads

2. 15~20 times faster under heavy production workloads

在HDD上效果明显。

InnoDB已经支持的prefetching feature "Linear Read Ahead"对提升全表扫描的性能并没有什么帮助，因为Linear Read Ahead是按照磁盘物理的page顺序做prefetch(默认64个page，这个范围太小了)。而稍大些的fragmented tables，逻辑上相邻的两个page在物理上距离一般会更大（文章中举例 page 3 -> page 5230 -> page 4）.

Logical Read Ahead基本原理：

根据primary key的B+树的branch节点记录的leaf page number信息，按照page的顺序（大部分转化为顺序读）将很多leaf节点的数据读入buffer pool，提升后续全表扫描时buffer pool的命中率，进而避免随机读。

实现思路（步骤）：

1.Reading many branch pages of the primary key

2.Collecting leaf page numbers

3.Reading many (configurable amount of) leaf pages by page number order (mostly sequential disk reads)

4.Reading rows by primary key order (same as usual full table scan, but buffer pool hit rate should be very high)

提供两个新的session variables:

1. innodb_lra_size; (the size of prefetch leaf pages)

2. innodb_lra_sleep; (???做啥用的？？？)

在需要使用LRA时将这个特性打开。

Submitting multiple async I/O requests at once

In 5.6, InnoDB开始默认使用aio。将多个连续的16KB读取一次submit，可以利用Linux对多个请求的merge，提高效率。

在HDD Raid 1+0的条件下，作者每次提交64个连续页面的读取请求，将读取效率由160MB/s提升至1000ＭＢ/s.

测试数据如下：

1. Full table scan on pure HDD (basic benchmark, no other workload)

Table size	Without LRA	With LRA	Improvement
10GB	10 min 55.00 sec	1 min 15.20 sec	8.71x
50GB	52 min 44.42 sec	6 min 36.98 sec	7.97x

2. Online schema change under heavy workload

Table size	Without LRA	With LRA	Improvement
1GB	7 min 33 sec	24 sec	18.8x

关于上述改进的三处改动都给了patch。

Facebook对MySQL全表扫描性能的改进相关推荐

深入理解为什么MySQL全表扫描很慢？
在InnoDB的数据页到底长什么样?这篇文章里,我们讲了InnoDB数据页长什么样,简单回顾下. 图1 InnoDB数据页结构示意图(图片来自网络) 其中有的部分没有详细讲解,因为暂时还用不到.比如P ...
33 | MySQL全表扫描会将内存打爆？（看了这篇你就赚）
一.前言本篇主要分析全表扫描对server层.引擎层的影响. 二.全表扫描对server层的影响 2.1.server端对结果集的保存流程是什么样的?MySQL 是"边读边发的" ...
mysql 全表扫描、全索引扫描、索引覆盖(覆盖索引)
full index scan:全索引扫描,查询时,遍历索引树来获取数据行.如果数据不是密集的会产生随机IO 在执行计划中是Type列,index full table scan:通过读物理表获取数据 ...
mysql全表扫描和用索引的区别
全表扫描的意思就是要把表中所有数据过一遍才能显示数据结果,索引扫描就是索引,只需要扫描一部分数据就可以得到结果, 打个比方吧,在新华字典中,如果没有拼音或笔画索引,当我们查找"做" ...
mysql什么情况会扫描所有_造成MySQL全表扫描的原因
全表扫描是数据库搜寻表的每一条记录的过程,直到所有符合给定条件的记录返回为止.通常在数据库中,对无索引的表进行查询一般称为全表扫描:然而有时候我们即便添加了索引,但当我们的SQL语句写的不合理的时候也 ...
数据库CPU内存高以及全表扫描的原因
哪些情况数据库全表扫描 1. 使用null做为判断条件 2. 左模糊查询Like %XXX% 3. 使用or做为连接条件 4. 使用in时(not in) 5.使用not in时 6.使用!=或< ...
mysql没加引号导致全表扫描_mysql隐蔽的索引规则导致数据全表扫描
索引是为了加速数据的检索,但是不合理的表结构或适应不当则会起到反作用.我们在项目中就遇到过类似的问题,两个十万级别的数据表,在做连接查询的时候,查询时间达到了7000多秒还没有查出结果. 首先说明,关 ...
MYSQL避免全表扫描__如何查看sql查询是否用到索引(mysql)
MYSQL避免全表扫描 1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引 2.应尽量避免在 where 子句中对字段进行 null 值判断,否 ...
mysql in 子查询无法使用索引全表扫描慎用in
背景最近慢sql 性能优化发现一个调用频率高的sql 使用 in 子查询,导致外层全表扫描的问题? 为什么会产生这样的问题?特别强调在优化的使用发现使用in 和优化后的效果差距 300倍,可见全 ...

Facebook对MySQL全表扫描性能的改进

Facebook对MySQL全表扫描性能的改进相关推荐

最新文章

热门文章