环境
硬件：DELL 1950, 146G SAS 15K RPMS * 2, 8G Ram
软件：2.6.9-55.ELsmp x86_64, mysql 5.1.x
硬件：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个多小时，这是为什么呢？
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，提高速度
1. 删除过期日志表，或者放到线下的归档数据库上
2. 如果innodb buffer还有大量空闲的话，可以不定期执行select * from table，将这部分数据load到buffer中，减少备份时的物理I/O，提高速度
本文转自叶金荣51CTO博客，原文链接：http://blog.51cto.com/imysql/308978，如需转载请自行联系原作者
