这里介绍一个最近用得很多的一个小工具：。

主要有两个功能：

(1) 尽可能快的从一个非常大的mysqldump文件的分离出某个单表的备份文件

(2) 可以帮你把一个大的mysqldump文件，切割成非常小的单表备份文件（可继续做并行恢复）

(1) 如果把MySQL中某一个表数据弄丢了，需要从很大的mysqldump备份文件中恢复这个表

(2) 如果你想并行恢复整个mysqldump备份文件时，这个脚本可以帮你把大文件切割成多个小的单表备份文件，然后就可以方便并行恢复多个文件了

这里以实例的方式介绍如何使用该脚本：

(1) 从backup.sql文件中获取表process的备份：

tbdba-restore-mysqldump.pl -t process -f backup.sql

(2) 从backup.sql文件中获取数据库monitor中的表process的备份：

tbdba-restore-mysqldump.pl -t process -s monitor -f backup.sql

(3) 从backup.sql文件中获取多个表的备份文件（例如表process、users）：

tbdba-restore-mysqldump.pl -t process,user -s monitor -f backup.sql

(4) 直接接收来自管道的输出（如果你的mysqldump备份是压缩后，则可以使用）：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl -t process,user -s monitor

(5) 从backup.sql文件中获取数据库monitor下所有表的备份文件：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl -s monitor

(6) 从backup.sql文件中获取所有数据库下所有表的备份文件：

gunzip -c backup.sql.gz|tbdba-restore-mysqldump.pl --all-tables

(7) 使用-d参数，则可以看到切割的过程中的更多信息：

date && gunzip -c /backdir/backup.sql.gz|tbdba-restore-mysqldump.pl -d -a && date

(1) 如果指定了-s（获取某个数据库中的备份）参数，则脚本在成功截取需要恢复的表后就会立刻退出，所以如果你要恢复的表恰好在备份文件的比较靠前的位置时，该脚本的速度会非常快。

一个实际工作例子：

$ls -lh backup.sql.gz

-rw-r--r-- 1 mysql dba 14G Nov 21 04:49 backup.sql.gz

$date && gunzip -c backup.sql.gz|./tbdba-restore-mysqldump.pl -s monitor_general -t monitor_host_info && date

Fri Nov 25 14:35:06 CST 2011

Fri Nov 25 14:46:49 CST 2011

(the unzip of backup.sql.gz is 88G)

如果要全量恢复的话，根据经验值：88GB的sql文件完全恢复约需要400分钟（）。

(2) 为了让每个独立的单表备份文件能够准确恢复，脚本做了两个额外的处理工作：在每个单表备份前加上'use db'，让该表能够恢复到正确的数据库；为了让单表恢复时字符集不出错误，脚本在某个单表备份前加上了对应的SET NAMES utf8、SET TIME_ZONE等命令。

：这篇文章提到了三个办法，分别是：perl脚本（我这里的做法基本“雷同”），awk解析后切割，先恢复到临时库(对大文件这个不现实...)。对比了我们的Perl脚本，这里做了几个改进：可以同时解析出多个表；完成目标表的切割后，则立刻退出，不再扫描剩余部分；会把mysqldump头部输出放到每一个切割文件中，方便各种字符集的恢复；

：这篇文章介绍如何用Sed来完成这个工作。

：这位朋友则，想出一个“更损”的招：只给恢复用户赋予需要恢复的表的权限，然后用--force参数恢复整个mysqldump文件。

：这篇文章则对比了使用grep sed 和“权限控制”三种方法的速度。

最后，如果不喜欢mysqldump这种一股脑的备份方式，可以考虑试用mydumper。

OK，That's all.