分析数据不算大，备份却非常慢的原因

核心提示：环境硬件：DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram软件：2.6.9-55.ELsmp x86_64, mysql 5.1.x现象2个库，其中1个业务库下有20多个表，分析数据不算大，备份却非常慢的原因，表文件大小总量不到2G，另一个为日志库，可以不定期执行select * fro

环境

硬件：DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram

软件：2.6.9-55.ELsmp x86_64, mysql 5.1.x

现象

2个库，其中1个业务库下有20多个表，表文件大小总量不到2G。

另一个为日志库，下400多个表，大致是每天会产生5个表，其中有一个表较大，约400MB，总量约40多GB。

每次备份耗时较长，最严重的一次花了5个多小时才完成。

业务库为当前活动库，日志库则主要用作备份，每天日志归档，过期数据表很少有读写请求。

InnoDB Buffer Pool总共分配了2G，从系统命令 top 结果来看，mysqld 只分配了 1.7G 内存，buffer pool 并没有全部耗尽。

SHOW ENGINE INNODB STATUS 结果中也看到了，buffer pool 确实没用完，还有不少空闲的。

备份时，观察 vmstat 结果，发现 bi 和 bo 的量较大，而且两个的值基本相当，备份其中一个表约 500MB，耗时 46 秒。

按照这个耗时计算，全部备份出来也不需要5个多小时，这是为什么呢？

分析

大家先分析下，看是什么原因，稍后给出答案 :)

原因 其实问题原因很简单，但一般人不容易想到。那就是，那些历史的日志表，由于长时间不读取，大部分数据没有在innodb buffer中。所以，每次备份时，大部分数据都要产生大量的物理读，然后再产生物理写，然而该服务器只有2块硬盘，I/O性能有限，所以备份非常慢。

这时候，我们可以有几种解决办法：

1. 删除过期日志表，或者放到线下的归档数据库上

2. 如果innodb buffer还有大量空闲的话，可以不定期执行select * from table，将这部分数据load到buffer中，减少备份时的物理I/O，提高速度