13518219792
在数据库表丢失或损坏的情况下，备份你的数据库是很重要的。如果发生系统崩溃，你肯定想能够将你的表尽可能丢失最少的数据恢复到崩溃发生时的状态。有时，正是MySQL管理员造成破坏。管理员已经知道表以破坏，用诸如vi或Emacs等编辑器试图直接编辑它们，这对表绝对不是件好事！
创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都网站设计、做网站、昌黎网络推广、小程序开发、昌黎网络营销、昌黎企业策划、昌黎品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供昌黎建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com
备份数据库两个主要方法是用mysqldump程序或直接拷贝数据库文件（如用cp、cpio或tar等）。每种方法都有其优缺点：
• mysqldump与MySQL服务器协同操作。直接拷贝方法在服务器外部进行，并且你必须采取措施保证没有客户正在修改你将拷贝的表。如果你想用文件系统备份来备份数据库，也会发生同样的问题：如果数据库表在文件系统备份过程中被修改，进入备份的表文件主语不一致的状态，而对以后的恢复表将失去意义。文件系统备份与直接拷贝文件的区别是对后者你完全控制了备份过程，这样你能采取措施确保服务器让表不受干扰。
• mysqldump比直接拷贝要慢些。
• mysqldump生成能够移植到其它机器的文本文件，甚至那些有不同硬件结构的机器上。直接拷贝文件不能移植到其它机器上，除非你正在拷贝的表使用MyISAM存储格式。ISAM表只能在相似的硬件结构的机器上拷贝。在MySQL 3.23中引入的MyISAM表存储格式解决了该问题，因为该格式是机器无关的，所以直接拷贝文件可以移植到具有不同硬件结构的机器上。只要满足两个条件：另一台机器必须也运行MySQL 3.23或以后版本，而且文件必须以MyISAM格式表示，而不是ISAM格式。
不管你使用哪种备份方法，如果你需要恢复数据库，有几个原则应该遵守，以确保最好的结果：
• 定期实施备份。建立一个计划并严格遵守。
• 让服务器执行更新日志。当你在崩溃后需要恢复数据时，更新日志将帮助你。在你用备份文件恢复数据到备份时的状态后，你可以通过运行更新日志中的查询再次运用备份后面的修改，这将数据库中的表恢复到崩溃发生时的状态。
• 以文件系统备份的术语讲，数据库备份文件代表完全倾倒（full dump），而更新日志代表渐进倾倒（incremental dump）。
• 使用一种统一的和易理解的备份文件命名机制。象backup1、buckup2等不是特别有意义。当实施你的恢复时，你将浪费时间找出文件里是什么东西。你可能发觉用数据库名和日期构成备份文件名会很有用。例如：
• %mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02
• %mysqldump menagerie /usr/archives/mysql/menagerie.1999-10-02
• 你可能想在生成备份后压缩它们。备份一般都很大！你也需要让你的备份文件有过期期限以避免它们填满你的磁盘，就象你让你的日志文件过期那样。
• 用文件系统备份备份你的备份文件。如果遇上了一个彻底崩溃，不仅清除了你的数据目录，也清除了包含你的数据库备份的磁盘驱动器，你将真正遇上了麻烦。也要备份你的更新日志。
• 将你的备份文件放在不同于用于你的数据库的文件系统上。这将降低由于生成备份而填满包含数据目录的文件系统的可能性。
用于创建备份的技术同样对拷贝数据库到另一台机器有用。最常见地，一个数据库被转移到了运行在另一台主机上的服务器，但是你也可以将数据转移到同一台主机上的另一个服务器。
1 使用mysqldump备份和拷贝数据库
当你使用mysqldumo程序产生数据库备份文件时，缺省地，文件内容包含创建正在倾倒的表的CREATE语句和包含表中行数据的INSERT语句。换句话说，mysqldump产生的输出可在以后用作mysql的输入来重建数据库。
你可以将整个数据库倾倒进一个单独的文本文件中，如下：
%mysqldump samp_db /usr/archives/mysql/samp_db.1999-10-02
输出文件的开头看起来象这样：
# MySQL Dump 6.0# # Host: localhost Database: samp_db#---------------------------------------# Server version 3.23.2-alpha-log## Table structure for table 'absence'#CREATE TABLE absence( student_id int(10) unsigned DEFAULT '0' NOT NULL, date date DEFAULT '0000-00-00' NOT NULL, PRIMARY KEY (student_id,date));## Dumping data for table 'absence'#INSERT INTO absence VALUES (3,'1999-09-03');INSERT INTO absence VALUES (5,'1999-09-03');INSERT INTO absence VALUES (10,'1999-09-08');......
文件剩下的部分有更多的INSERT和CREATE TABLE语句组成。
如果你想压缩备份，使用类似如下的命令：
%mysqldump samp_db | gzip /usr/archives/mysql/samp_db.1999-10-02.gz
如果你要一个庞大的数据库，输出文件也将很庞大，可能难于管理。如果你愿意，你可以在mysqldump命令行的数据库名后列出单独的表名来倾到它们的内容，这将倾倒文件分成较小、更易于管理的文件。下例显示如何将samp_db数据库的一些表倾到进分开的文件中：
%mysqldump samp_db student score event absence grapbook.sql
%mysqldump samp_db member president hist-league.sql
如果你生成准备用于定期刷新另一个数据库内容的备份文件，你可能想用--add-drop-table选项。这告诉服务器将DROP TABLE IF EXISTS语句写入备份文件，然后，当你取出备份文件并把它装载进第二个数据库时，如果表已经存在，你不会得到一个错误。
如果你倒出一个数据库以便能把数据库转移到另一个服务器，你甚至不必创建备份文件。要保证数据库存在于另一台主机，然后用管道倾倒数据库，这样mysql能直接读取mysqldump的输出。例如：你想从主机pit-viper.snake.net拷贝数据库samp_db到boa.snake.net，可以这样很容易做到：
%mysqladmin -h boa.snake.net create samp_db
%mysqldump samp_db | mysql -h boa.snake.net samp_db
以后，如果你想再次刷新boa.snake.net上的数据库，跳过mysqladmin命令，但要对mysqldump加上--add-drop-table以避免的得到表已存在的错误：
%mysqldump --add-drop-table samp_db | mysql -h boa.snake.net samp_db
mysqldump其它有用的选项包括：
• --flush-logs和--lock-tables组合将对你的数据库检查点有帮助。--lock-tables锁定你正在倾倒的所有表，而--flush-logs关闭并重新打开更新日志文件，新的更新日志将只包括从备份点起的修改数据库的查询。这将设置你的更新日志检查点位备份时间。（然而如果你有需要执行个更新的客户，锁定所有表对备份期间的客户访问不是件好事。）
• 如果你使用--flush-logs设置检查点到备份时，有可能最好是倾倒整个数据库。如果你倾倒单独的文件，较难将更新日志检查点与备份文件同步。在恢复期间，你通常按数据库为基础提取更新日志内容，对单个表没有提取更新的选择，所以你必须自己提取它们。
• 缺省地，mysqldump在写入前将一个表的整个内容读进内存。这通常确实不必要，并且实际上如果你有一个大表，几乎是失败的。你可用--quick选项告诉mysqldump只要它检索出一行就写出每一行。为了进一步优化倾倒过程，使用--opt而不是--quick。--opt选项打开其它选项，加速数据的倾倒和把它们读回。
• 用--opt实施备份可能是最常用的方法，因为备份速度上的优势。然而，要警告你，--opt选项确实有代价，--opt优化的是你的备份过程，不是其他客户对数据库的访问。--opt选项通过一次锁定所有表阻止任何人更新你正在倾倒的任何表。你可在一般数据库访问上很容易看到其效果。当你的数据库一般非常频繁地使用，只是一天一次地调节备份。
• 一个具有--opt的相反效果的选项是--dedayed。该选项使得mysqldump写出INSERT DELAYED语句而不是INSERT语句。如果你将数据文件装入另一个数据库并且你想是这个操作对可能出现在该数据库中的查询的影响最小，--delayed对此很有帮助。
• --compress选项在你拷贝数据库到另一台机器上时很有帮助，因为它减少网络传输字节的数量。下面有一个例子，注意到--compress对与远端主机上的服务器通信的程序才给出，而不是对与本地主机连接的程序：
%mysqldump --opt samp_db | mysql --compress -h boa.snake.net samp_db
• mysqldump有很多选项，详见《MySQL参考手册》。
2 使用直接拷贝数据库的备份和拷贝方法
另一种不涉及mysqldump备份数据库和表的方式是直接拷贝数据库表文件。典型地，这用诸如cp、tar或cpio实用程序。本文的例子使用cp。
当你使用一种直接备份方法时，你必须保证表不在被使用。如果服务器在你则正在拷贝一个表时改变它，拷贝就失去意义。
保证你的拷贝完整性的最好方法是关闭服务器，拷贝文件，然后重启服务器。如果你不想关闭服务器，要在执行表检查的同时锁定服务器。如果服务器在运行，相同的制约也适用于拷贝文件，而且你应该使用相同的锁定协议让服务器“安静下来”。
假设服务器关闭或你已经锁定了你想拷贝的表，下列显示如何将整个samp_db数据库备份到一个备份目录（DATADIR表示服务器的数据目录）：
%cdDATADIR%cp -r samp_db /usr/archive/mysql
单个表可以如下备份：
%cdDATADIR/samp_db%cp member.* /usr/archive/mysql/samp_db%cp score.* /usr/archive/mysql/samp_db ....
当你完成了备份时，你可以重启服务器（如果关闭了它）或释放加在表上的锁定（如果你让服务器运行）。
要用直接拷贝文件把一个数据库从一台机器拷贝到另一台机器上，只是将文件拷贝到另一台服务器主机的适当数据目录下即可。要确保文件是MyIASM格式或两台机器有相同的硬件结构，否则你的数据库在另一台主机上有奇怪的内容。你也应该保证在另一台机器上的服务器在你正在安装数据库表时不访问它们。
3 复制数据库（Replicating Database）
复制（Replication）类似于拷贝数据库到另一台服务器上，但它的确切含义是实时地保证两个数据库的完全同步。这个功能将在3.23版中出现，而且还不很成熟，因此本文不作详细介绍。
4 用备份恢复数据
数据库损坏的发生有很多原因，程度也不同。如果你走运，你可能仅损坏一两个表（如掉电），如果你倒霉，你可能必须替换整个数据目录（如磁盘损坏）。在某些情况下也需要恢复，比如用户错误地删除了数据库或表。不管这些倒霉事件的原因，你将需要实施某种恢复。
如果表损坏但没丢失，尝试用myisamchk或isamchk修复它们，如果这样的损坏可有修复程序修复，你可能根本不需要使用备份文件。关于表修复的过程，见《数据库维护与修复》。
恢复过程涉及两种信息源：你的备份文件和个更新日志。备份文件将表恢复到实施备份时的状态，然而一般表在备份与发生问题之间的时间内已经被修改，更新日志包含了用于进行这些修改的查询。你可以使用日志文件作为mysql的输入来重复查询。这已正是为什么要启用更新日志的原因。
恢复过程视你必须恢复的信息多少而不同。实际上，恢复整个数据库比单个表跟容易，因为对于数据库运用更新日志比单个表容易。
4.1 恢复整个数据库
首先，如果你想恢复的数据库是包含授权表的mysql数据库，你需要用--skip-grant-table选项运行服务器。否则，它会抱怨不能找到授权表。在你已经恢复表后，执行mysqladmin flush-privileges告诉服务器装载授权标并使用它们。
• 将数据库目录内容拷贝到其它某个地方，如果你在以后需要它们。
• 用最新的备份文件重装数据库。如果你用mysqldump产生的文件，将它作为mysql的输入。如果你用直接从数据库拷贝来的文件，将它们直接拷回数据库目录，然而，此时你需要在拷贝文件之前关闭数据库，然后重启它。
使用更新日志重复做备份以后的修改数据库表的查询。对于任何可适用的更新日志，将它们作为mysql的输入。指定--one-database选项使得mysql只执行你有兴趣恢复的数据库的查询。如果你知道你需要运用所有更新日志文件，你可以在包含日志的目录下使用这条命令：
% ls -t -r -1 update.[0-9]* | xargs cat | mysql --one-databasedb_name
ls命令生成更新日志文件的一个单列列表，根据服务器产生它们的次序排序（主意：如果你修改任何一个文件，你将改变排序次序，这导致更新日志一错误的次序被运用。）
很可能你会是运用某几个更新日志。例如，自从你备份以来产生的更新日志被命名为update.392、update.393等等，你可以这样重新运行：
%mysql --one-database db_name update.392
%mysql --one-database db_name update.393
.....
如果你正在实施恢复且使用更新日志恢复由于一个错误建议的DROP DATABASE、DROP TABLE或DELETE语句造成丢失的信息，在运用更新日志之前，要保证从其中删除这些语句。
4.2 恢复单个表
恢复单个表较为复杂。如果你用一个由mysqldump生成的备份文件，并且它不包含你感兴趣的表的数据，你需要从相关行中提取它们并将它们用作mysql的输入。这是容易的部分。难的部分是从只运用于该表的更新日志中拉出片断。你会发觉mysql_find_rows实用程序对此很有帮助，它从更新日志中提取多行查询。
另一个可能性是使用另一台服务器恢复整个数据库，然后拷贝你想要的表文件到原数据库中。这可能真的很容易！当你将文件拷回数据库目录时，要确保原数据库的服务器关闭。
至于用php语句写mysql备份，涉及一些php课程，我也不是太懂，不好意思~~
1、首先打开mysql数据库软件进入软件主界面。
2、然后再左侧树里打开自己的的数据库。
3、然后需要点击需要备份的数据库名。
4、如图所示为打开数据库后界面。
5、然后需要点击转储sql文件选项。
6、然后需要打开选择存储文件路径并选择保存。
7、点击保存即可在路径备份好格式为sql的数据库文件。
目前 MySQL 支持的免费备份工具有：mysqldump、mysqlhotcopy，还可以用 SQL 语法进行备份：BACKUP TABLE 或者 SELECT INTO OUTFILE，又或者备份二进制日志（binlog），还可以是直接拷贝数据文件和相关的配置文件。MyISAM 表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。Innodb 所有的表都保存在同一个数据文件 ibdata1 中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump。
1、mysqldump
1.1 备份
mysqldump 是采用SQL级别的备份机制，它将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之间升级时相对比较合适，这也是最常用的备份方法。现在来讲一下 mysqldump 的一些主要参数：
•--compatible=name
它告诉 mysqldump，导出的数据将和哪种数据库或哪个旧版本的 MySQL 服务器相兼容。值可以为 ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options 等，要使用几个值，用逗号将它们隔开。当然了，它并不保证能完全兼容，而是尽量兼容。
•--complete-insert，-c
导出的数据采用包含字段名的完整 INSERT 方式，也就是把所有的值都写在一行。这么做能提高插入效率，但是可能会受到 max_allowed_packet 参数的影响而导致插入失败。因此，需要谨慎使用该参数，至少我不推荐。
•--default-character-set=charset
指定导出数据时采用何种字符集，如果数据表不是采用默认的 latin1 字符集的话，那么导出时必须指定该选项，否则再次导入数据后将产生乱码问题。
•--disable-keys
告诉 mysqldump 在 INSERT 语句的开头和结尾增加 /*!40000 ALTER TABLE table DISABLE KEYS */; 和 /*!40000 ALTER TABLE table ENABLE KEYS */; 语句，这能大大提高插入语句的速度，因为它是在插入完所有数据后才重建索引的。该选项只适合 MyISAM 表。
•--extended-insert = true|false
默认情况下，mysqldump 开启 --complete-insert 模式，因此不想用它的的话，就使用本选项，设定它的值为 false 即可。
•--hex-blob
使用十六进制格式导出二进制字符串字段。如果有二进制数据就必须使用本选项。影响到的字段类型有 BINARY、VARBINARY、BLOB。
•--lock-all-tables，-x
在开始导出之前，提交请求锁定所有数据库中的所有表，以保证数据的一致性。这是一个全局读锁，并且自动关闭 --single-transaction 和 --lock-tables 选项。
•--lock-tables
它和 --lock-all-tables 类似，不过是锁定当前导出的数据表，而不是一下子锁定全部库下的表。本选项只适用于 MyISAM 表，如果是 Innodb 表可以用 --single-transaction 选项。
•--no-create-info，-t
只导出数据，而不添加 CREATE TABLE 语句。
•--no-data，-d
不导出任何数据，只导出数据库表结构。
•--opt
这只是一个快捷选项，等同于同时添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 选项。本选项能让 mysqldump 很快的导出数据，并且导出的数据能很快导回。该选项默认开启，但可以用 --skip-opt 禁用。注意，如果运行 mysqldump 没有指定 --quick 或 --opt 选项，则会将整个结果集放在内存中。如果导出大数据库的话可能会出现问题。
•--quick，-q
该选项在导出大表时很有用，它强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。
•--routines，-R
导出存储过程以及自定义函数。
•--single-transaction
该选项在导出数据之前提交一个 BEGIN SQL语句，BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表，例如 InnoDB 和 BDB。本选项和 --lock-tables 选项是互斥的，因为 LOCK TABLES 会使任何挂起的事务隐含提交。要想导出大表的话，应结合使用 --quick 选项。
•--triggers
同时导出触发器。该选项默认启用，用 --skip-triggers 禁用它。
其他参数详情请参考手册，我通常使用以下 SQL 来备份 MyISAM 表：
/usr/local/mysql/bin/mysqldump -uyejr -pyejr --default-character-set=utf8 --opt --extended-insert=false \
--triggers -R --hex-blob -x db_name db_name.sql
使用以下 SQL 来备份 Innodb 表：
/usr/local/mysql/bin/mysqldump -uyejr -pyejr --default-character-set=utf8 --opt --extended-insert=false \
--triggers -R --hex-blob --single-transaction db_name db_name.sql
1.2 还原
用 mysqldump 备份出来的文件是一个可以直接倒入的 SQL 脚本，有两种方法可以将数据导入。
•直接用 mysql 客户端
例如：
/usr/local/mysql/bin/mysql -uyejr -pyejr db_name db_name.sql
•用 SOURCE 语法
其实这不是标准的 SQL 语法，而是 mysql 客户端提供的功能，例如：
SOURCE /tmp/db_name.sql;
这里需要指定文件的绝对路径，并且必须是 mysqld 运行用户(例如 nobody)有权限读取的文件。
2、 mysqlhotcopy
2.1 备份
mysqlhotcopy 是一个 PERL 程序，最初由Tim Bunce编写。它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 来快速备份数据库。它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件（包括数据表定义文件、数据文件、索引文件）所在的机器上。mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在 类Unix 和 NetWare 系统上。
mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。以下是几个例子：
root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name /tmp (把数据库目录 db_name 拷贝到 /tmp 下)
root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name_1 ... db_name_n /tmp
root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr db_name./regex/ /tmp
更详细的使用方法请查看手册，或者调用下面的命令来查看 mysqlhotcopy 的帮助：
perldoc /usr/local/mysql/bin/mysqlhotcopy
注意，想要使用 mysqlhotcopy，必须要有 SELECT、RELOAD(要执行 FLUSH TABLES) 权限，并且还必须要能够有读取 datadir/db_name 目录的权限。
2.2 还原
mysqlhotcopy 备份出来的是整个数据库目录，使用时可以直接拷贝到 mysqld 指定的 datadir (在这里是 /usr/local/mysql/data/)目录下即可，同时要注意权限的问题，如下例：
root#cp -rf db_name /usr/local/mysql/data/
root#chown -R nobody:nobody /usr/local/mysql/data/ (将 db_name 目录的属主改成 mysqld 运行用户)
3、 SQL 语法备份
3.1 备份
BACKUP TABLE 语法其实和 mysqlhotcopy 的工作原理差不多，都是锁表，然后拷贝数据文件。它能实现在线备份，但是效果不理想，因此不推荐使用。它只拷贝表结构文件和数据文件，不同时拷贝索引文件，因此恢复时比较慢。例子：
BACK TABLE tbl_name TO '/tmp/db_name/';
注意，必须要有 FILE 权限才能执行本SQL，并且目录 /tmp/db_name/ 必须能被 mysqld 用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。
SELECT INTO OUTFILE 则是把数据导出来成为普通的文本文件，可以自定义字段间隔的方式，方便处理这些数据。例子：
SELECT INTO OUTFILE '/tmp/db_name/tbl_name.txt' FROM tbl_name;
注意，必须要有 FILE 权限才能执行本SQL，并且文件 /tmp/db_name/tbl_name.txt 必须能被 mysqld 用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。
3.2 恢复
用 BACKUP TABLE 方法备份出来的文件，可以运行 RESTORE TABLE 语句来恢复数据表。例子：
RESTORE TABLE FROM '/tmp/db_name/';
权限要求类似上面所述。
用 SELECT INTO OUTFILE 方法备份出来的文件，可以运行 LOAD DATA INFILE 语句来恢复数据表。例子：
LOAD DATA INFILE '/tmp/db_name/tbl_name.txt' INTO TABLE tbl_name;
权限要求类似上面所述。倒入数据之前，数据表要已经存在才行。如果担心数据会发生重复，可以增加 REPLACE 关键字来替换已有记录或者用 IGNORE 关键字来忽略他们。
补充:
shell mysqldump --quick db_name | gzip db_name.contents.gz(该例子中创建的文件是压缩格式）。
恢复/转移到另一台的命令如下:
shell gunzip db_name.contents.gz | mysql db_name以上命令,适用于*nix 操作系统的机器
4、 启用二进制日志(binlog)
采用 binlog 的方法相对来说更灵活，省心省力，而且还可以支持增量备份。
启用 binlog 时必须要重启 mysqld。首先，关闭 mysqld，打开 my.cnf，加入以下几行：
server-id = 1
log-bin = binlog
log-bin-index = binlog.index
然后启动 mysqld 就可以了。运行过程中会产生 binlog.000001 以及 binlog.index，前面的文件是 mysqld 记录所有对数据的更新操作，后面的文件则是所有 binlog 的索引，都不能轻易删除。关于 binlog 的信息请查看手册。
需要备份时，可以先执行一下 SQL 语句，让 mysqld 终止对当前 binlog 的写入，就可以把文件直接备份，这样的话就能达到增量备份的目的了：
FLUSH LOGS;如果是备份复制系统中的从服务器，还应该备份 master.info 和 relay-log.info 文件。
备份出来的 binlog 文件可以用 MySQL 提供的工具 mysqlbinlog 来查看，如：
/usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001
该工具允许你显示指定的数据库下的所有 SQL 语句，并且还可以限定时间范围，相当的方便，详细的请查看手册。
恢复时，可以采用类似以下语句来做到：
/usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001 | mysql -uyejr -pyejr db_name
把 mysqlbinlog 输出的 SQL 语句直接作为输入来执行它。
如果你有空闲的机器，不妨采用这种方式来备份。由于作为 slave 的机器性能要求相对不是那么高，因此成本低，用低成本就能实现增量备份而且还能分担一部分数据查询压力，何乐而不为呢？
5、 直接备份数据文件
相较前几种方法，备份数据文件最为直接、快速、方便，缺点是基本上不能实现增量备份。为了保证数据的一致性，需要在靠背文件前，执行以下 SQL 语句：
FLUSH TABLES WITH READ LOCK;也就是把内存中的数据都刷新到磁盘中，同时锁定数据表，以保证拷贝过程中不会有新的数据写入。这种方法备份出来的数据恢复也很简单，直接拷贝回原来的数据库目录下即可。
注意，对于 Innodb 类型表来说，还需要备份其日志文件，即 ib_logfile* 文件。因为当 Innodb 表损坏时，就可以依靠这些日志文件来恢复。
6、 备份策略
对于中等级别业务量的系统来说，备份策略可以这么定：第一次全量备份，每天一次增量备份，每周再做一次全量备份，如此一直重复。而对于重要的且繁忙的系统来说，则可能需要每天一次全量备份，每小时一次增量备份，甚至更频繁。为了不影响线上业务，实现在线备份，并且能增量备份，最好的办法就是采用主从复制机制(replication)，在 slave 机器上做备份。
7、 数据维护和灾难恢复
作为一名DBA(我目前还不是，呵呵)，最重要的工作内容之一是保证数据表能安全、稳定、高速使用。因此，需要定期维护你的数据表。以下 SQL 语句就很有用：
CHECK TABLE 或 REPAIR TABLE，检查或维护 MyISAM 表
OPTIMIZE TABLE，优化 MyISAM 表
ANALYZE TABLE，分析 MyISAM 表
当然了，上面这些命令起始都可以通过工具 myisamchk 来完成，在这里不作详述。
Innodb 表则可以通过执行以下语句来整理碎片，提高索引速度：
ALTER TABLE tbl_name ENGINE = Innodb;
这其实是一个 NULL 操作，表面上看什么也不做，实际上重新整理碎片了。
通常使用的 MyISAM 表可以用上面提到的恢复方法来完成。如果是索引坏了，可以用 myisamchk 工具来重建索引。而对于 Innodb 表来说，就没这么直接了，因为它把所有的表都保存在一个表空间了。不过 Innodb 有一个检查机制叫 模糊检查点，只要保存了日志文件，就能根据日志文件来修复错误。可以在 my.cnf 文件中，增加以下参数，让 mysqld 在启动时自动检查日志文件：
innodb_force_recovery = 4
关于该参数的信息请查看手册。
有点长 慢慢看 对你应该有帮助
下面我们就看一下常见的备份工具，以及目前最流行的 Percona XtraBackup 的备份流程。
MySQL 常见的备份工具主要分为三种：
这里先说一下 binlog 备份，它只是把 binlog 又复制了一份，并且需要在逻辑备份或者物理备份的基础上才能进行数据恢复，无法单独进行数据恢复。
mysqldump 备份出的文件就是 sql 文件，其核心就是对每个表执行 select ，然后转化成相应的 insert 语句。mysqldump 的备份流程大致如下：
从上面可以看出在 mysqldump 备份期间，备份到某个数据库时，该数据库下的表都会处于只读状态，无法对表进行任何变更，直到该库下的表备份完毕，这对于线上环境一般是无法接受的。若是指定了--master-data或者 --dump-slave 则会在备份开始时加全局读锁（FLUSH TABLES WITH READ LOCK），直到备份结束。当然我们可以选一个从库进行备份，这样就不会影响线上业务。另外使用 mysqldump 备份还有一个最大的好处，因为备份出来的是 sql 语句，所以它支持跨平台和跨版本的数据迁移或者恢复，这是物理备份无法做到的。
但是也正是因为 mysqldump 备份出来的是 sql 语句，在使用时要更加注意，否则可能会酿成大祸。例如，使用 mysqldump 常见的问题有：
所以使用 mysqldump 时一定要了解各个选项的作用，以及确认备份出来的 sql 文件里会有什么操作，会对现有数据造成什么影响。
Mydumper 原理与 Mysqldump 原理类似，最大的区别是引入了多线程备份，每个备份线程备份一部分表，当然并发粒度可以到行级，达到多线程备份的目的。这里不再单独介绍。
Percona XtraBackup 是 Percona 公司开发的一个用于 MySQL 数据库物理热备的备份工具，是基于 InnoDB 的崩溃恢复功能来实现的。它的基本工作原理如下：
Percona XtraBackup 在进行恢复时会应用拷贝的 redo log ，应用已提交的事务，回滚未提交的事物，将数据库恢复到一致性状态。因为 Percona XtraBackup 备份出来的是物理文件，所以在使用备份出的文件进行恢复或者迁移时，不会像 mysqldump 那样会存在很多问题。
使用 XtraBackup 备份时根据备份参数设置不同，对数据库的变更会造成不同程度的影响，具体影响会在下文分析。
通过对比发现，XtraBackup 具有对数据库影响小，且能快速恢复的优点，在日常备份中是首选；mysqldump 使用相对更加灵活，但是使用是要注意对数据库原有数据的影响。
备份策略主要有：全量备份和增量备份，再加上 binlog 备份。
目前去哪儿网数据库备份主要采用 XtraBackup 全量备份 +binlog 备份。数据库的重要级别不同，全量备份的频率不同。备份程序主要架构如下：
说明：
Percona XtraBackup 是目前备份 MySQL 使用最广泛的工具。在备份过程中，数据库可以进行正常的读写或者其他变更操作，但是偶尔也会遇见备份引起的元数据锁，或提交事务时发现被 binlog lock 阻塞等情况。下面我们就看一下 Percona XtraBackup 的备份流程和加锁时机。
说明：以下对 Percona XtraBackup 的分析都是基于 2.4.23 的版本，其他版本会略有差别，但是关键步骤基本相同。
XtraBackup 在备份开始时，会创建一个后台线程，专门用于拷贝数据库的 redo log 。首先 XtraBackup 会扫描每组 redo log 的头部，找出当前的 checkpoint lsn ，然后从该 lsn 后顺序拷贝所有的 redo log ，包括后续新产生的 redo log 。该线程会一直持续到将非事务表完全拷贝完成，才会安全退出。备份日志输出中会记录拷贝开始时的 checkpoint lsn 。日志输出如下：
在拷贝ibd文件之前，会先扫描数据库的数据文件目录，获取ibdata1，undo tablespaces及所有的ibd文件列表，并会记录相应的 space id，因为在恢复时需要这些 space id来找到对应 doublewrite buffer里页面的内容，以及对应的redo log条目。然后开始循环拷贝ibdata1，undo tablespaces及所有的ibd文件。
这里可通过设置--parallel进行多线程备份，提高物理文件的拷贝效率。不设置则默认为1。
在所有ibd文件拷贝完成后，XtraBackup开始备份非ibd文件。这一部分的逻辑比较复杂，因为备份非ibd文件前需要加锁，具体是否会加锁主要受到--no-lock 参数设置的影响。
若是设置了--no-lock为TRUE，则不会使用"FLUSH TABLES WITH READ LOCK"去加全局读锁，但是若备份过程中对non-InnoDB表执行了DDL或者DML操作， 这会导致备份的不一致，恢复出来的数据就会有问题。所以是不建议将--no-lock为TRUE，默认值是FALSE，也就是在不指定该选项的情况下会在备份非ibd文件前加全局读锁。
下面我们结合源码来看看判断是否加全局锁这部分的具体流程逻辑：
流程图如下：
总结来看：
1）若--no-lock为FALSE（默认值），则先施加全局读锁，然后再进行拷贝文件，另外若 --safe-slave-backup 设置为TRUE ，则会在加全局锁之前关闭SQL_THREAD线程；
2）若--no-lock为TRUE，则不会施加锁，直接进行拷贝文件。
加锁的逻辑主要由lock_tables_maybe实现,先看一下lock_tables_maybe源代码，如下：
lock_tables_maybe 函数简化处理流程如下：
1）若备份实例上已经加锁（ LOCK TABLES FOR BACKUP / FLUSH TABLES WITH READ LOCK）或者设置lock-ddl-per-table 则直接返回；
2）若支持备份锁，则执行LOCK TABLES FOR BACKUP；
3）若不支持备份锁，则执行 FLUSH TABLES WITH READ LOCK。根据相应选项设置，在执行该操作前会判断是否有执行中的DDL/DML，以及等待超时时间，是否kill 对应的未结束的事务等。
从上文中我们还看到一个参数--safe-slave-backup ，该参数的主要作用是：
若是在从库执行的备份操作时设置了该参数，可以防止因从库同步主库操作，而导致XtraBackup长时间请求不到锁而造成备份失败。
若是设置了 --safe-slave-backup 为TRUE，那么会执行"STOP SLAVE SQL_THREAD"，并等待Slave_open_temp_tables 为零才开始拷贝非 ibd 文件，Slave_open_temp_tables 为零说明SQL thread执行的事务都已经完成，这样就能保证备份的一致性。并且此时也不会有在执行的事务阻塞 XtraBackup 施加全局锁。
备份完非 ibd 文件后，将会备份 slave 和 binlog 信息。
mysql-bin.000004 2004 6b7bda9f-15f0-11ec-ba14-fa163ea367a4:1-83,9841546e-15f0-11ec-9557-fa163e736db4:1
需要注意，在支持备份锁的实例上备份，指定了 --slave-info 或--binlog-info 均会先施加 binlog 备份锁（ LOCK BINLOG FOR BACKUP），这会阻塞任何会更改 binlog 位点的操作。
备份完数据库的所有文件和binlog等相关信息，备份工作就基本完成了，之后主要执行的操作如下：
1）执行"FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS",将所有的redo log刷盘；
2）停止redo log复制线程；
3）释放全局读锁（备份锁），binlog锁；
4）开启SQL_THREAD；
5）拷贝ib_buffer_pool和ib_lru_dump文件；
6）生成配置文件backup-my.cnf；
7）打印备份信息到xtrabackup_info文件，这些信息主要包含备份时使用的参数信息，备份起止时间，binlog位点信息，以及将会回到的lsn点。
下面是xtrabackup_info记录的部分内容：
加锁对应的函数是 mdl_lock_tables ，释放锁对应的函数是 mdl_unlock_all，主要是执行COMMIT，结束 mdl_lock_tables 中开启的显式事务，来释放MDL锁。mdl_lock_tables 流程如下：
上面参数--lock-ddl和--lock-ddl-per-table是在 Percona XtraBackup 2.4.8 之后添加的，因为 MySQL 5.7 新增了一个叫做 Sorted Index Builds 的功能，这会导致某些 DDL 操作不记录重做日志而导致备份失败。使用--lock-ddl或--lock-ddl-per-table 就会在备份开始时施加锁，阻止 DDL 操作。
另外，若备份时指定了--lock-ddl或--lock-ddl-per-table，则在备份非 ibd 文件时就不是再有加锁操作。
注意：LOCK TABLES FOR BACKUP和LOCK BINLOG FOR BACKUP 语句只有在支持备份锁的实例上才会执行，Percona Server for MySQL已经在 5.6.16-64.0 版本开始支持这种更加轻量的备份锁。
Q1: 使用 XtraBackup 备份的文件进行恢复时，恢复到哪个时间点？ A1：恢复到执行 LOCK BINLOG FOR BACKUP 或 FLUSH TABLES WITH READ LOCK 的时间点，因为这时任何改变 binlog 位点的操作都会被阻塞，redo log和binlog 是一致的。
Q2: 在开启 binlog 的情况下，MySQL 的奔溃恢复是同时依赖 binlog 和 redo log 这两种日志的，为什么XtraBackup 不用备份binlog？
A2：因为在备份中有执行LOCK BINLOG FOR BACKUP/FLUSH TABLES WITH READ LOCK，阻止了任何改变binlog位点的操作，这样只需要根据redo log将有commit log 的事务提交，没有commit log的事务进行回滚即可。
Q3: 使用Percona XtraBackup备份完成后redo的位点是和binlog是一样还是比binlog多一些？
A3：通过分析备份流程可以发现备份 binlog 位点信息（加binlog锁）是发生在停止 redo 拷贝线程前，而释放锁是在停止 redo 拷贝线之后，所以 redo log 会多一些。锁住了 binlog 保证了在该 binlog 位点前已经提交的事务的 redo log 都有 commit log 的信息，未提交的事物也就没有对应的 commit log 的信息，即便在锁住 binlog 后有 Innodb 表新的 DML 产生的 redo log ，但是事务无法提交，也就没有 commit log 的信息的，最后在回放的过程中对没有 commit log 的事务进行回滚就可以了。
Q4：Percona XtraBackup什么时候会加锁，以及影响加锁时间长度的因素有哪些？
A4：上面进行了分析，加锁操作只在备份非 ibd 文件时执行，加锁时长主要和非事务表的数量和大小有关，非事务表的数量越多，体积越大，拷贝文件所用的时间越长，那么加锁时间也就越长。也会和 redo log 生成的速度有关，只是 redo log 刷盘受到多个因素的影响，未及时刷盘的 redo log 一般很小。
Q5：Percona XtraBackup 和mysqldump选择哪个更好？
A5：通过上面的的解析，若是整个实例备份，首先选择 Percona XtraBackup ，因为对数据库的影响最小。若只是备份某个库表，这个就要视数据量而定，若数据量不大可以使用 mysqldump 。注意，对数据库做备份时最好选择业务连接最少的从库，因为备份也会消耗一定的资源，避免影响业务。
数据库的自动备份，可以减轻维护者的工作量也便于系统恢复，对于比较重要的数据库，最好还是设置下自动备份。
工具/原料
navicat for mysql
mysql 5.5
方法/步骤
打开navicat客户端，连上mysql后，双击左边你想要备份的数据库。点击“计划”，再点击“新建批处理作业”。
双击上面的可用任务，它就会到下面的列表里去，代表你选择了这个任务。
点击保存，弹出个命名对话框，给这个任务取个名字，点击“确定”
点击“设置”计划任务。
弹出的对话框，选择“计划”，再点击“新建”。
这里设置为从2014年1月24号起每天早上九点备份该数据库。如果想提高备份频率、或者设置备份截止日期，请点击“高级”。
高级选项可以把备份设置的更精细，比如这里设置的是在24小时内每隔2小时就备份一次。加上前面的基本设置，任务计划就是：从2014年1月24号开始，每天九点，每隔2小时备份一次，每天的备份都持续24小时。
最后，输入电脑密码就大功告成。
MyISAM 表是保存成文件的形式，因此相对比较容易备份，上面提到的几种方法都可以使用。Innodb 所有的表都保存在同一个数据文件 ibdata1 中（也可能是多个文件，或者是独立的表空间文件），相对来说比较不好备份，免费的方案可以是拷贝数据文件、备份 binlog，或者用 mysqldump。1. 使用直接拷贝数据库备份 典型的如cp、tar或cpio实用程序当你使用直接备份方法时，必须保证表不在被使用。如果服务器在你正在拷贝一个表时改变它，拷贝就失去意义。保证你的拷贝完整性的最好方法是关闭服务器，拷贝文件，然后重启服务器。 如果你不想关闭服务器，要在执行表检查的同时锁定服务器。如果服务器在运行，相同的制约也适用于拷贝文件，应该使用相同的锁定协议让服务器“安静下来”。当你完成了MySQL数据库备份时，需要重启服务器（如果关闭了它）或释放加在表上的锁定（如果你让服务器运行）。 要用直接拷贝文件把一个数据库从一台机器拷贝到另一台机器上，只是将文件拷贝到另一台服务器主机的适当数据目录下即可。要确保文件是MyIASM格式或两台机器有相同的硬件结构，否则你的数据库在另一台主机上有奇怪的内容。你也应该保证在另一台机器上的服务器在你正在安装数据库表时不访问它们。2. 使用mysqldump数据库备份mysqldump 是采用SQL级别的备份机制，它将数据表导成 SQL 脚本文件，在不同的 MySQL 版本之间升级时相对比较合适，这也是最常用的备份方法。mysqldump程序备份数据库较慢，但它生成的文本文件便于移植。mysqldump 的一些主要参数：1）--compatible=name它告诉 mysqldump，导出的数据将和哪种数据库或哪个旧版本的 MySQL 服务器相兼容。值可以为 ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options 等，要使用几个值，用逗号将它们隔开。当然了，它并不保证能完全兼容，而是尽量兼容。2）--complete-insert，-c导出的数据采用包含字段名的完整 INSERT 方式，也就是把所有的值都写在一行。这么做能提高插入效率，但是可能会受到 max_allowed_packet 参数的影响而导致插入失败。因此，需要谨慎使用该参数，至少我不推荐。3）--default-character-set=charset指定导出数据时采用何种字符集，如果数据表不是采用默认的 latin1 字符集的话，那么导出时必须指定该选项，否则再次导入数据后将产生乱码问题。4）--disable-keys告诉mysqldump 在 INSERT 语句的开头和结尾增加 ; 和 ; 语句，这能大大提高插入语句的速度，因为它是在插入完所有数据后才重建索引的。该选项只适合 MyISAM 表。5）--extended-insert = true|false默认情况下，mysqldump 开启 --complete-insert 模式，因此不想用它的的话，就使用本选项，设定它的值为 false 即可。6）--hex-blob使用十六进制格式导出二进制字符串字段。如果有二进制数据就必须使用本选项。影响到的字段类型有 BINARY、VARBINARY、BLOB。7）--lock-all-tables，-x在开始导出之前，提交请求锁定所有数据库中的所有表，以保证数据的一致性。这是一个全局读锁，并且自动关闭 --single-transaction 和 --lock-tables 选项。8）--lock-tables它和--lock-all-tables 类似，不过是锁定当前导出的数据表，而不是一下子锁定全部库下的表。本选项只适用于 MyISAM 表，如果是 Innodb 表可以用 --single-transaction 选项。9）--no-create-info，-t只导出数据，而不添加 CREATE TABLE 语句。10）--no-data，-d不导出任何数据，只导出数据库表结构。11）--opt这只是一个快捷选项，等同于同时添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 选项。本选项能让 mysqldump 很快的导出数据，并且导出的数据能很快导回。该选项默认开启，但可以用 --skip-opt 禁用。注意，如果运行 mysqldump 没有指定 --quick 或 --opt 选项，则会将整个结果集放在内存中。如果导出大数据库的话可能会出现问题。12）--quick，-q该选项在导出大表时很有用，它强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。13）--routines，-R导出存储过程以及自定义函数。14）--single-transaction该选项在导出数据之前提交一个 BEGIN SQL语句，BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表，例如 InnoDB 和 BDB。 本选项和 --lock-tables 选项是互斥的，因为 LOCK TABLES 会使任何挂起的事务隐含提交。 要想导出大表的话，应结合使用 --quick 选项。--triggers同时导出触发器。该选项默认启用，用 --skip-triggers 禁用它。备份：使用mysqldump备份数据库其实就是把数据库转储成一系列CREATE TABLE和INSERT语句，通过这些语句我们就可重新生成数据库。使用mysqldump的方法如下：% mysqldump --opt testdb | gzip /data/backup/testdb.bak#--opt选项会对转储过程进行优化，生成的备份文件会小一点，后的管道操作会进行数据压缩% mysqldump --opt testdb mytable1,mytable2 | gzip /data/backup/testdb_mytable.bak#可在数据库后接数据表名，只导出指定的数据表，多个数据表可用逗号分隔--opt选项还可激活--add-drop-table选项，它将会在备份文件的每条CREATE TABLE前加上一条DROP TABLE IF EXISTS语句。这可方便进行数据表的更新，而不会发生“数据表已存在”的错误。用mysqldump命令还可直接把数据库转移到另外一台服务器上，不用生成备份文件。重复执行可定期更新远程数据库。% mysqladmin -h remote_host create testdb% mysqldump --opt testdb | mysql -h remote_host testdb另外还可通过ssh远程调用服务器上的程序，如：% ssh remote_host mysqladmin create testdb% mysqldump --opt testdb | ssh remote_host mysql testdb 通过直接拷贝系统文件的方式备份数据库，在备份时，要确保没有人对数据库进行修改操作。要做到这点，最好关闭服务器。如果不能关闭的，要以只读方试锁定有关数据表。下面是一些示例：% cp -r db /backup/db #备份db数据库到/backup/db目录% cp table_name.* /backup/db #只备份table_name数据表% scp -r db remotehot:/usr/local/mysql/data #用scp把数据库直接拷贝到远程服务器，在把数据库直接拷贝到远程主机时，应注意两台机器必须有同样的硬件结构，或者将拷贝的数据表全部是可移植数据表类型。或者/usr/local/mysql/bin/mysqldump -uroot -proot \--default-character-set=utf8 --opt --extended-insert=false \--triggers -R --hex-blob -x testdb testdb.sql使用以下 SQL 来备份 Innodb 表：/usr/local/mysql/bin/mysqldump -uroot -proot \--default-character-set=utf8 --opt --extended-insert=false \--triggers -R --hex-blob --single-transaction testdb testdb.sql另外，如果想要实现在线备份，还可以使用 --master-data 参数来实现，如下：/usr/local/mysql/bin/mysqldump -uroot -proot \--default-character-set=utf8 --opt --master-data=1 \--single-transaction --flush-logs testdb testdb.sql它只是在一开始的瞬间请求锁表，然后就刷新binlog了，而后在导出的文件中加入CHANGE MASTER 语句来指定当前备份的binlog位置，如果要把这个文件恢复到slave里去，就可以采用这种方法来做。 还原：用mysqldump 备份出来的文件是一个可以直接倒入的 SQL 脚本，有两种方法可以将数据导入。直接用 mysql 客户端例如：/usr/local/mysql/bin/mysql -uroot -proot testdb testdb.sql用SOURCE 语法其实这不是标准的 SQL 语法，而是 mysql 客户端提供的功能，例如：SOURCE /tmp/testdb.sql;这里需要指定文件的绝对路径，并且必须是 mysqld 运行用户(例如 nobody)有权限读取的文件。 3. 使用mysqlhotcopy数据库备份 使用mysqlhotcopy工具，它是一个Perl DBI脚本，可在不关闭服务器的情况下备份数据库，mysqlhotcopy 是一个 PERL 程序，最初由Tim Bunce编写。它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 来快速备份数据库。它是备份数据库或单个表的最快的途径，但它只能运行在数据库文件（包括数据表定义文件、数据文件、索引文件）所在的机器上。mysqlhotcopy 只能用于备份 MyISAM，并且只能运行在 类Unix 和 NetWare 系统上。它主要的优点是：它直接拷贝文件，所以它比mysqldump快。可自动完成数据锁定工作，备份时不用关闭服务器。能刷新日志，使备份文件和日志文件的检查点能保持同步。备份：mysqlhotcopy 支持一次性拷贝多个数据库，同时还支持正则表达。以下是几个例子：/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=root -p=root \testdb /tmp (把数据库目录 testdb 拷贝到 /tmp 下)/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=root -p=root \testdb_1 testdb_2 testdb_n /tmp/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=root -p=root \testdb./regex/ /tmp 还原：mysqlhotcopy 备份出来的是整个数据库目录，使用时可以直接拷贝到 mysqld 指定的 datadir (在这里是 /usr/local/mysql/data/)目录下即可，同时要注意权限的问题，如下例：cp -rf testdb /usr/local/mysql/data/chown -R nobody:nobody /usr/local/mysql/data/ (将 testdb 目录的属主改成 mysqld 运行用户) 4. 使用SQL语句数据库备份 BACKUP TABLE 语法其实和 mysqlhotcopy 的工作原理差不多，都是锁表，然后拷贝数据文件。它能实现在线备份，但是效果不理想，因此不推荐使用。它只拷贝表结构文件和数据文件，不同时拷贝索引文件，因此恢复时比较慢。备份：BACK TABLE tbl_test TO '/tmp/testdb/'; #把tbl_test数据库备份到/tmp/testdb/目录里，会自动创建一个testdb目录 为了执行该语句，你必须拥有那些表的FILE权限和SELECT权限，备份目录还必须是服务器可写的。该语句执行时，会先把内存中的数据写入磁盘，再把各个数据表的.frm(表结构定义文件)、.MYD(数据)文件从数据目录拷贝到备份目录。它不拷贝.MYI(索引)文件，因为它能用另外两个文件重建。BACKUP TABLE语句备份时，依次锁定数据表，当同时备份多个数据表时，数据表可能会被修改，所以备份0完成时，备份文件中的数据和现时数据表中的数据可能会有差异，为了消除该差异，我们可用只读方式锁定数据表，在备份完成后再解锁。如：mysql LOCK TABLES tb1 READ,tb2 READ;mysql BACKUP TABLE tb1,tb2 TO 'backup/db';mysql UNLOCK TABLES;使用BACKUP TABLE语句备份的数据表可用RESTORE TABLE重新加载到服务器。注意，必须要有 FILE 权限才能执行本SQL，并且目录 /tmp/testdb/ 必须能被 mysqld 用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。SELECT INTO OUTFILE 则是把数据导出来成为普通的文本文件，可以自定义字段间隔的方式，方便处理这些数据。 例子：SELECT * INTO OUTFILE '/tmp/testdb/tbl_test.txt' FROM tbl_test;注意，必须要有 FILE 权限才能执行本SQL，并且文件 /tmp/testdb/tbl_test.txt 必须能被 mysqld 用户可写，导出的文件不能覆盖已经存在的文件，以避免安全问题。还原：用BACKUP TABLE 方法备份出来的文件，可以运行 RESTORE TABLE 语句来恢复数据表。例子：RESTORE TABLE FROM '/tmp/testdb/';权限要求类似上面所述。用SELECT INTO OUTFILE 方法备份出来的文件，可以运行 LOAD DATA INFILE 语句来恢复数据表。例子：LOAD DATA INFILE '/tmp/testdb/tbl_name.txt' INTO TABLE tbl_name;权限要求类似上面所述。倒入数据之前，数据表要已经存在才行。
以上回答你满意么？
