乐观备份是 MySQL Enterprise Backup 3.11 引入的一个特性，用于提高备份和恢复仅少量表被频繁修改的庞大数据库的性能。

在对一个巨大的数据库（例如，以 TB 为单位）进行热备份时，备份过程中可能会在服务器上生成巨大的重做日志文件。由于重做日志文件的增长速度超过了 mysqlbackup 处理它们的速度 ，当mysqlbackup无法赶上重做日志周期并且 LSN 在被mysqlbackup读取之前被服务器覆盖时，备份操作实际上可能会失败。此外，为恢复准备备份apply-log的步骤 可能需要很长时间，因为 mysqlbackup有巨大的 ibbackup_logfile文件（从大重做日志文件创建）应用于备份。当备份和恢复过程中可用于读写重做日志的 I/O 资源不足时，问题会更加严重。

乐观备份通过将备份过程分为两个内部阶段来缓解这些问题，这两个阶段对用户是透明的：

optimistic-time只要使用或 optimistic-busy-tables选项， 就会发生乐观备份 。有关如何使用这些选项，请参阅第 14.10 节“性能/可伸缩性/容量选项”中的详细说明。如果正如预期的那样，由 optimistic 选项标识的非活动表列表在备份期间没有改变（或者，即使它改变了很小的百分比），大多数用户会发现整体备份时间与普通备份相比显着减少备份，因为要备份的重做日志数据的大小将小得多。此外，备份的恢复时间也将减少，因为 apply-log由于较小的重做日志，操作会快得多。然而，如果事实证明在备份过程中标识的非活动表列表发生了很大一部分更改，则执行乐观备份的好处将变得有限，在最坏的情况下，乐观备份实际上可能需要更长的时间来执行和，对于单个文件的备份，与普通备份相比，备份的大小会更大。 因此，用户在尝试执行乐观备份 时应谨慎识别哪些表“不活动”，哪些表“繁忙” 。

以下示例说明了如何进行乐观备份。

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=110516120000 backup

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-time=now backup

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*"  backup

当您同时使用optimistic-time和 optimistic-busy-tables选项并且它们在确定哪些表将成为繁忙表时发生冲突时， optimistic-busy-tables优先于 optimistic-time. 例如：

mysqlbackup --defaults-file=/etc/my.cnf --optimistic-busy-tables="^mydatabase\.mytables-.*"  \
--optimistic-time=100516 backup