主要有两个功能：

(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等命令。

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

Restore a Single Table From mysqldump：这篇文章介绍如何用Sed来完成这个工作。

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

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

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

OK，That's all.

广告：我们寻找靠谱的人 | 感谢作者

1.基本使用

mysqldump -ubackup -p --all-databases > ~/dz_dump.sql
mysqldump -ubackup -p --databases feel> ~/feel_dump.sql #仅备份单个数据库
mysqldump -ubackup -p --no-data --all-databases> ~/no_data.sql #仅备份表结构

2.关于INFORMATION_SCHEMA

information_schema是由mysql server维护的一个数据库，在备份数据库的时候，我们是不需要这个数据库的。事实情况也很好，5.0、5.1版本下的mysqldump都是不会导出这个数据库的。但是4.1的mysqldump不买这个帐，会将information_schema一起导出，这是不必要的。（使用4.1版本的mysqldump必须使用--single-transaction参数，因为即使是root用户也不能lock information_schema里面的数据表）

3.使用备份做备库

--master-info可以帮你用备份出来的数据做一个备库

4.较大的数据量

如果你的数据量，到了几千万的级别，mysqldump的速度就会变的很慢，而且dump生成的文件会很大，你想从备份恢复数据库时间也会很长，这时候，你可能需要寻找新的备份方法了

5."Lost connection to MySQL server"

在使用mysqldump的时候（尤其是向NFS上备份的时候），很多人都被'mysqldump:Got error:2013: Lost connection to MySQL server during query when dumping table'的问题困扰，在Manual中对这个问题有一些简单的说明。

在向NFS上备份的时候，数据的流向是这样的：MySQL Server端从数据文件中检索出数据，然后分批将数据返回给mysqldump客户端，然后mysqldump将数据写入到NFS上。一般地，向NFS上写入数据的速度较之Server端检索发送数据的速度要慢得多，这就会导致mysqldump无法及时的接受Server端发送过来的数据，Server端的数据就会积压在内存中等待发送，这个等待不是无限期的，当Server的等待时间超过net_write_timeout（默认是60秒）时它就失去了耐心，mysqldump的连接会被断开，同时抛出错误Got error: 2013: Lost connection。

增加net_write_timeout可以解决上述的问题的。在实践中发现，在增大net_write_timeout后，Server端会消耗更多的内存，有时甚至会导致swap的使用（并不确定是不是修改net_write_timeout所至）。建议在mysqldump之前修改net_write_timeout为一个较大的值（如1800），在mysqldump结束后，在将这个值修改到默认的60。

6.备份和恢复速度

经验值：某个备份出的.sql文件大小为39GB，备份耗时约80分钟；在测试恢复中，发现需要约206分钟。环境：Quad-Core AMD Opteron(tm) 4*2核32G内存；

7.其他

*****备份不要在数据库压力较大的时候进行，每天凌晨备份是比较合适的

*****如果是事务型引擎（InnoDB），建议使用--single-transaction参数，这样可以让锁表时间变得很短

参考：

1. Manual about mysqldump
2. Manual about Lost Connection
3. Manual about net_write_timeout

一般来说，你有两种可供选择的备份MySQL的方式----mysqldump 或者mysqlhotcopy。

mysqldump可以备份各种类型的数据表，但是mysqlhotcopy只适合备份MyISAM和ISAM的数据表。所以使用mysqlhotcopy之前，你必须确认你的数据表是不是有其他的存储引擎(storage engines)的。

How To：

1. mysqldump -uroot -p*** DBNAME | gzip -f>/backup/dbname.'date +%w'.dump.gz
2. mysqlhotcopy DBNAME -u root -p *** /backup

两者速度：因为mysqlhotcopy会直接拷贝存储数据的文件，所以其速度是依赖于磁盘操作的速度，较之mysqldump要快些。下面是两种方式备份同一个数据的时候的时间消耗比较：

1. mysqldump  耗时22分39秒（gzip压缩后文件大小为747M.）
2. mysqlhotcopy  耗时6分07秒（tar gzip打包压缩后文件大小为1014M.）

参考：

1. http://dev.mysql.com/doc/refman/5.0/en/backup.html
2. ttp://www.mysqlperformanceblog.com/2009/03/03/10-things-you-need-to-know-about-backup-solutions-for-mysql/