本节介绍使用 MySQL Enterprise Backup 备份数据库的性能注意事项。在优化和调整备份过程时，测量原始性能（完成备份需要多长时间）和数据库服务器的开销量。衡量备份性能时，请考虑：
您的备份程序强加的限制。例如，如果您每 8 小时进行一次备份，则备份必须在 8 小时内完成。
您的网络和存储基础架构施加的限制。例如，如果您需要在特定存储设备上容纳多个备份，您可能会使用压缩备份，即使这会使备份过程变慢。
备份时间和恢复时间之间的权衡。如果这些选项使还原速度更快，您可能会选择一组导致备份速度稍慢的选项。有关还原过程的性能信息，请参见 第 11.2 节 “优化还原性能”。
完整或增量备份
进行完整备份后，可以通过增量备份更快地执行后续备份，其中仅备份更改的数据。对于增量备份，请
为mysqlbackup--incremental指定或
--incremental-with-redo-log-only选项。有关这些选项的信息，请参阅
第 16.7 节，“增量备份选项”。有关增量备份的备份和应用阶段的使用说明，请参阅
第 4.3.3 节，“进行差异备份或增量备份”。
压缩备份
在将备份数据传输到另一台服务器之前压缩备份数据会在进行备份的数据库服务器上产生额外的 CPU 开销，但在作为备份数据的最终目的地的服务器上会减少网络流量和磁盘 I/O。在决定是否使用压缩时，请考虑数据库服务器上的负载、网络带宽以及数据库和目标服务器的相对容量。有关创建压缩备份的信息，请参阅 第 4.3.4 节“制作压缩备份”和 第 16.6 节“压缩选项”。
压缩涉及备份性能和恢复性能之间的权衡。在紧急情况下，在恢复备份数据之前解压缩备份数据所需的时间可能是不可接受的。如果数据库服务器上没有足够的可用空间来保存压缩备份和未压缩数据，也可能存在存储问题。因此，数据越重要，您就越有可能选择不使用压缩：接受较慢、较大的备份以确保恢复过程尽可能快速和可靠。
单文件备份
单文件备份本身不一定比生成输出文件目录树的传统备份类型更快。它的性能优势来自组合不同的步骤，否则您可能必须按顺序执行这些步骤，例如将备份数据组合成一个输出文件并将其传输到另一台服务器。有关单文件备份的选项 ，请参阅 第 15.5 节，“其他单文件备份操作” ，有关使用说明，请参阅第4.3.1 节，“制作单文件备份”。
InnoDB 配置选项设置
正如后面所讨论的，您可能更喜欢使用设置运行的原因有很多
innodb_file_per_table=1。
并行备份
mysqlbackup可以利用现代多核 CPU 和操作系统线程来并行执行备份操作。请参阅 第 16.10 节，“性能/可伸缩性/容量选项”以了解用于控制备份过程的不同方面使用多少线程的选项。如果您发现备份期间有未使用的系统容量，请考虑增加这些选项的值并测试这样做是否会提高备份性能：
使用 RAID 存储配置调整和测试备份性能时，请考虑选项设置的组合
--read-threads=3 --process-threads=6 --write-threads=3。与组合进行比较--read-threads=1 --process-threads=6 --write-threads=1。使用非 RAID 存储配置调整和测试备份性能时，请考虑选项设置的组合
--read-threads=1 --process-threads=6 --write-threads=1。当您增加 3 个 “线程”选项中任何一个的值时，也会增加该
--limit-memory选项的值，以便为额外的线程提供足够的内存来完成它们的工作。如果 CPU 不太忙（CPU 使用率低于 80%），请增加该
--process-threads选项的值。如果您从中备份的存储设备（源驱动器）可以处理更多 I/O 请求，请增加该
--read-threads选项的值。如果要备份到的存储设备（目标驱动器）可以处理更多 I/O 请求，请增加该
--write-threads选项的值（不适用于始终使用单个写入线程的单文件备份）。
根据您的操作系统，您可以使用top、
iostat、sar、
dtrace或图形性能监视器等命令来测量资源利用率。iowait一旦系统值达到大约 20%
，就不要增加读取或写入线程的数量
。
MyISAM 注意事项
尽管mysqlbackup在不中断数据库使用的情况下备份 InnoDB 表，但复制非 InnoDB 文件（例如 MyISAM 表和
.frm文件）的最后阶段使用语句将数据库暂时置于只读状态FLUSH TABLES WITH READ LOCK。为了获得最佳备份性能并将对数据库处理的影响降到最低：不要
SELECT在备份运行时运行长查询或其他 SQL 语句。保持您的 MyISAM 表相对较小，主要用于只读或以读为主的工作。
然后mysqlbackup运行 结束时的锁定阶段 很短（可能是几秒钟），并且不会过多地干扰 mysqld的正常处理。如果您的数据库应用程序不满足上述条件，请使用
--only-innodb或--only-innodb-with-frm选项仅备份 InnoDB 表，或使用该--no-locking选项备份非 InnoDB 文件。请注意，如果在备份的最后阶段更新了 MyISAM、.frm和其他在该--no-locking设置下复制的文件，则不能保证它们是一致的。对于大型数据库，备份运行可能需要很长时间。始终检查mysqlbackup是否已成功完成，方法是验证 mysqlbackup返回退出代码 0，或观察mysqlbackup已打印文本“ mysqlbackup 已完成 OK！”。
在没有涉及表的 DDL 操作运行期间安排备份。有关与 DDL 操作同时进行备份的限制 ，请参阅 附录 B，MySQL Enterprise Backup的限制。
网络性能
对于数据处理操作，您可能知道 Unix 套接字在与数据库通信时比 TCP/IP 更快的传统建议。尽管mysqlbackup
命令支持选项
--protocol=tcp、
--protocol=socket和
--protocol=pipe，但这些选项对备份或恢复性能没有显着影响。这些过程涉及文件复制操作而不是客户端/服务器网络流量。由--protocol选项控制的数据库通信是低容量的。例如，mysqlbackup通过数据库连接获取数据库参数信息，但不获取表或索引数据。
数据大小
如果某些表或数据库包含非关键信息，或者很少更新，您可以将它们排除在最频繁的备份之外，并按不太频繁的计划进行备份。有关相关选项的信息，请参阅 第 16.8 节，“部分备份和恢复选项” ，有关从特定表、数据库或存储引擎中删除数据的说明，请参阅第4.3.5 节，“进行部分备份” 。部分备份速度更快，因为它们复制、压缩和传输的数据量较小。
要最小化数据文件的总体大小InnoDB，请考虑启用 MySQL 配置选项
innodb_file_per_table。此选项可以通过InnoDB多种方式最小化表的数据大小：
它防止
InnoDB系统表空间的大小膨胀，分配以后只能由 MySQL 使用的磁盘空间。例如，有时只是临时需要大量数据，或者在实验过程中错误地加载了数据。如果没有该innodb_file_per_table选项，系统表空间会扩展以容纳所有这些数据，并且此后永远不会缩小。InnoDB当表被删除或截断时，它会立即释放表及其索引 占用的磁盘空间 。每个表及其关联的索引都由一个.ibd 文件表示，该文件被这些 DDL 操作删除或清空。当删除大量数据或删除索引时，它允许语句
.ibd回收文件中 未使用的空间。OPTIMIZE TABLE如第 4.3.5 节“进行部分备份”中所述， 它支持部分备份，您可以在其中备份一些
InnoDB表而不 备份其他表。它允许对 InnoDB 表使用表压缩。
通常，通过
ROW_FORMAT=COMPRESSED减小表大小并提高备份和恢复性能来使用表压缩。但是，作为权衡，表压缩可能会增加重做日志的大小，从而减慢增量备份和恢复以及
apply-log操作的速度。有关详细信息，请参阅
InnoDB 表的压缩工作原理。
避免创建查询未使用的索引。因为索引会占用备份数据的空间，所以不必要的索引会减慢备份过程。（
mysqlbackup使用的复制和扫描机制不依赖索引来完成它们的工作。）例如，在表的每一列上创建索引通常没有帮助，因为任何查询只使用一个索引。由于主键列包含在每个
InnoDB二级索引中，定义由大量或冗长的列组成的主键，或者相同列的不同排列的多个二级索引会浪费空间。
高级：应用日志阶段（仅适用于目录备份）
If you store the backup data on a separate machine, and that machine is not as busy the machine hosting the database server, you can offload some postprocessing work (the apply-log phase) to that separate machine. Apply-log Operation
在初始备份后立即执行应用日志阶段（使恢复更快）或将其推迟到恢复之前（使备份更快）之间总是存在性能权衡。在紧急情况下，恢复性能是最重要的考虑因素。因此，数据越重要，备份后立即运行应用日志阶段就越重要。通过指定选项将备份和应用日志阶段组合在同一台服务器上
backup-and-apply-log，或者执行快速初始备份，将备份数据传输到另一台服务器，然后使用
Apply-log中的选项之一执行应用日志阶段操作。