时间点恢复是指恢复自给定时间点以来所做的数据更改。通常，这种类型的恢复是在恢复完整备份后执行的，该备份使服务器恢复到备份时的状态。（完整备份可以通过多种方式进行，例如 第 7.2 节“数据库备份方法”中列出的方式。）时间点恢复然后使服务器从完整备份时间增量更新到更多最近的时间。
这里的许多示例使用mysql客户端来处理mysqlbinlog
生成的二进制日志输出
。如果您的二进制日志包含
（空）字符，则除非您使用该选项
调用它，否则
mysql\0无法解析该输出。--binary-mode
时间点恢复基于以下原则：
时间点恢复的信息源是由完整备份操作之后生成的二进制日志文件表示的一组增量备份。因此，服务器必须
--log-bin以启用二进制日志记录的选项启动（请参阅第 5.4.4 节，“二进制日志”）。要从二进制日志中恢复数据，您必须知道当前二进制日志文件的名称和位置。默认情况下，服务器在数据目录中创建二进制日志文件，但可以指定一个路径名，并
--log-bin选择将文件放在不同的位置。第 5.4.4 节，“二进制日志”。要查看所有二进制日志文件的列表，请使用以下语句：
mysql> SHOW BINARY LOGS;要确定当前二进制日志文件的名称，请发出以下语句：
mysql> SHOW MASTER STATUS;mysqlbinlog实用程序将二进制日志文件中 的事件从二进制格式转换为文本，以便可以执行或查看它们。mysqlbinlog 具有根据事件时间或事件在日志中的位置选择二进制日志部分的选项。请参阅 第 4.6.8 节，“mysqlbinlog — 处理二进制日志文件的实用程序”。
从二进制日志执行事件会导致重做它们所代表的数据修改。这使得能够恢复给定时间跨度内的数据更改。要从二进制日志执行事件，请 使用mysql客户端处理mysqlbinlog输出 ：
$> mysqlbinlog binlog_files | mysql -u root -p当您需要确定事件时间或位置以在执行事件之前选择部分日志内容时，查看日志内容会很有用。要从日志中查看事件，请将 mysqlbinlog输出发送到分页程序中：
$> mysqlbinlog binlog_files | more或者，将输出保存在文件中并在文本编辑器中查看该文件：
$> mysqlbinlog binlog_files > tmpfile $> ... edit tmpfile ...将输出保存在文件中对于在删除某些事件（例如意外的
DROP DATABASE. 在执行其内容之前，您可以从文件中删除任何不执行的语句。编辑文件后，执行内容如下：$> mysql -u root -p < tmpfile
如果要在 MySQL 服务器上执行多个二进制日志，安全的方法是使用到服务器的单个连接来处理它们。这是一个演示可能不安全的示例：
$> mysqlbinlog binlog.000001 | mysql -u root -p # DANGER!!
$> mysqlbinlog binlog.000002 | mysql -u root -p # DANGER!!CREATE TEMPORARY
TABLE如果第一个日志文件包含一个语句而第二个日志包含一个使用临时表的语句，那么使用与
服务器的不同连接以这种方式处理二进制日志会导致问题
。当第一个
mysql进程终止时，服务器会删除临时表。当第二个mysql进程尝试使用该表时，服务器报告“未知表。”
为避免此类问题，请使用单个 连接来执行要处理的所有二进制日志的内容。这是一种方法：
$> mysqlbinlog binlog.000001 binlog.000002 | mysql -u root -p另一种方法是将所有日志写入单个文件，然后处理该文件：
$> mysqlbinlog binlog.000001 > /tmp/statements.sql
$> mysqlbinlog binlog.000002 >> /tmp/statements.sql
$> mysql -u root -p -e "source /tmp/statements.sql"
在从包含 GTID 的二进制日志中读回时写入转储文件时（请参阅第 17.1.3 节，“使用全局事务标识符进行复制”），使用mysqlbinlog--skip-gtids的选项
，如下所示：
$> mysqlbinlog --skip-gtids binlog.000001 > /tmp/dump.sql
$> mysqlbinlog --skip-gtids binlog.000002 >> /tmp/dump.sql
$> mysql -u root -p -e "source /tmp/dump.sql"