IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

数据不算大,备份却非常慢

MySQL 中文网 2009-10-19 23:22:05 累计浏览 2,176 次
本机暂存

    问题

    环境

    硬件: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 结果,发现 bibo 的量较大,而且两个的值基本相当,备份其中一个表约 500MB,耗时 46 秒。

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

    分析

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

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

    这时候,我们可以有几种解决办法:

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

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

同分类推荐文章

  1. 使用deepseek进行Oracle恢复,引起重大故障 (2026-06-22 10:56:00)
  2. 接手一个只差临门一脚的数据库恢复 (2026-06-18 00:13:09)
  3. 我做了一个 AI 版的 StarRocks 升级风险扫描工具,直接帮我定位到一个风险 (2026-06-15 01:00:00)

查看更多 数据库 文章 →

建议继续学习

  1. 用Hyer来进行网站的抓取 (累计阅读 158,252)
  2. 如何成为Python高手 (累计阅读 54,992)
  3. MySQL数据库在实际应用一些方面的介绍 (累计阅读 36,400)
  4. WordPress插件开发 -- 在插件使用数据库存储数据 (累计阅读 29,164)
  5. Mysql监控指南 (累计阅读 21,352)
  6. 由浅入深探究mysql索引结构原理、性能分析与优化 (累计阅读 16,523)
  7. 在Apache2.2.XX下安装Mod-myvhost模块 (累计阅读 13,058)
  8. Linux 性能监控、测试、优化工具 (累计阅读 13,013)
  9. include(“./file.php”)和include(“file.php”)区别 (累计阅读 12,790)
  10. 15个最好的免费开源电子商务平台 (累计阅读 12,541)