MySQL企业备份3.11版本说明
本节描述使用MySQL Enterprise Backup备份数据库时的性能考虑因素。在优化和调优备份过程时，测量原始性能(完成备份需要多长时间)和数据库服务器上的开销。在度量备份性能时，需要考虑:
备份过程所施加的限制。例如，如果每8小时进行一次备份，则备份时间必须小于8小时。
网络和存储基础设施施加的限制。例如，如果需要在特定的存储设备上放置多个备份，则可以使用压缩备份，即使这样会使备份过程变慢。
备份时间和恢复时间之间的权衡。如果这些选项使还原速度大大提高，则可以选择一组导致备份速度稍慢的选项。看到第7.2节，“优化恢复性能”有关恢复过程的性能信息。
全量备份或增量备份
在执行完全备份之后，可以通过执行增量备份更快地执行后续备份，其中只备份更改的数据。对于增量备份，请指定——增量或——incremental-with-redo-log-only选项mysqlbackup．看到第5.1.8节“增量备份选项”有关这些选项的信息。有关增量备份的备份和应用阶段的使用说明，请参见第3.3.2节“增量备份”而且例4.3，“将增量备份应用于完全备份”．
压缩备份
在将备份数据传输到另一台服务器之前对其进行压缩，会导致在进行备份的数据库服务器上产生额外的CPU开销，但在作为备份数据最终目的地的服务器上减少网络流量和磁盘I/O。在决定是否使用压缩时，要考虑数据库服务器上的负载、网络带宽以及数据库和目标服务器的相对容量。看到第3.3.3节，“进行压缩备份”而且第5.1.7节“压缩选项”有关创建压缩备份的信息。
压缩涉及到备份性能和恢复性能之间的权衡。在紧急情况下，在恢复备份数据之前解压缩备份数据所需的时间可能是不可接受的。如果数据库服务器上没有足够的空闲空间来同时保存压缩备份和未压缩数据，则可能会出现存储问题。因此，数据越关键，就越有可能选择不使用压缩:接受较慢、较大的备份，以确保恢复过程尽可能快速和可靠。
单文件备份
单文件备份本身并不一定比生成输出文件目录树的传统类型的备份快。它的性能优势来自于组合不同的步骤，否则您可能不得不按顺序执行，例如将备份数据组合到一个输出文件中并将其传输到另一个服务器。看到第5.1.1.5节“使用单文件备份”有关单文件备份的选项，和第3.3.5节“进行单文件备份”使用指令。
InnoDB Configuration Options设置
在MySQL 5.5之前，通常的做法是保持重做日志相当小，以避免在MySQL服务器被杀死而不是正常关闭时花费很长的启动时间。在MySQL 5.5及以上版本，性能为崩溃恢复有显著改善，如优化InnoDB配置变量．使用这些版本，你可以让你的重做日志文件更大，如果这有助于你的备份策略和数据库工作负载。
正如后面所讨论的，您可能更喜欢使用该设置运行，原因有很多innodb_file_per_table = 1．
并行备份
的mysqlbackup命令可以利用现代的多核cpu和操作系统线程并行执行备份操作。看到第5.1.11节“性能/可伸缩性/容量选项”用于控制备份进程的不同方面使用多少线程的选项。如果在备份过程中发现有未使用的系统容量，请考虑增加这些选项的值，并测试这样做是否会提高备份性能:
在使用RAID存储配置调优和测试备份性能时，请考虑选项设置的组合
——read-threads = 3——流程线程= 6——帖子= 3．对比组合——read-threads = 1——流程线程= 6帖子= 1．在使用非raid存储配置调优和测试备份性能时，请考虑选项设置的组合
——read-threads = 1——流程线程= 6帖子= 1．当你增加任意3的值时”线程”选项，也增加了值
——limit-memory选项，为额外的线程提供足够的内存来完成它们的工作。如果CPU不是太忙(CPU利用率小于80%)，则增加
——流程线程选择。如果进行备份的存储设备(源驱动器)可以处理更多的I/O请求，请增加
——read-threads选择。如果要备份到的存储设备(目标驱动器)可以处理更多的I/O请求，请增加
——帖子的选择。
根据您的操作系统，您可以使用诸如前，iostat，特别行政区，dtrace，或图形性能监视器。不增加读或写线程的数量iowait一旦系统iowait价值达到约20%。
MyISAM注意事项
重要的
虽然mysqlbackup命令在不中断数据库使用的情况下备份InnoDB表，最后阶段复制非InnoDB文件(如MyISAM表和
.frmFiles)使用语句临时将数据库置于只读状态用读锁刷新表．为了获得最佳的备份性能和对数据库处理的最小影响:不要跑太久
选择查询或其他SQL语句。保持MyISAM表相对较小，主要用于只读或以读为主的工作。
然后锁定阶段的末尾mysqlbackup运行时间较短(可能只有几秒钟)，并且不影响正常的处理mysqld多。如果您的数据库应用程序不满足上述条件，请使用
——only-innodb或——only-innodb-with-frm选项只备份InnoDB表，或者使用——无固定选项用于备份非innodb文件。注意,MyISAM,.frm目录下的其他文件——无固定如果在备份的最后阶段更新设置，则不能保证它们是一致的。对于大型数据库，备份运行可能需要很长时间。总是检查mysqlbackup已成功完成，要么通过验证mysqlbackup命令返回退出代码0，或者观察它mysqlbackup已打印文本”mysqlbackup完成好的!”．
的mysqlbackup命令和前者不一样”MySQL备份”开源项目从MySQL 6.0源代码树。MySQL企业备份产品取代了MySQL备份计划。
在没有运行涉及表的DDL操作时计划备份。看到A.1节“MySQL企业备份的限制”以限制在DDL操作的同时进行备份。
网络性能
对于数据处理操作，您可能知道Unix套接字在与数据库通信方面比TCP/IP更快的传统建议。虽然mysqlbackup命令支持以下选项——= tcp协议，——协议=套接字,——协议=管，这些选项对备份或恢复性能没有显著影响。这些过程涉及文件复制操作，而不是客户机/服务器网络流量。控件控制的数据库通信——协议选择是容量。例如,mysqlbackup通过数据库连接检索有关数据库参数的信息，但不检索表或索引数据。
数据大小
如果某些表或数据库包含不重要的信息，或者很少更新，那么可以将它们排除在最频繁的备份之外，并以较不频繁的时间表备份它们。看到第5.1.9节“部分备份和恢复选项”有关相关选项的信息，和第3.3.4节“进行部分备份”有关从特定表、数据库或存储引擎中删除数据的说明。部分备份速度更快，因为它们复制、压缩和传输的数据量更小。
使…的整体尺寸最小InnoDB数据文件，考虑启用MySQL配置选项innodb_file_per_table．此选项可使的数据大小最小化InnoDB表有以下几种方式:
它阻止了
InnoDB系统表空间的膨胀，分配的磁盘空间以后只能被MySQL使用。例如，有时候大量的数据只是暂时需要的，或者是错误加载的，或者是在实验期间加载的。没有innodb_file_per_table选项，则系统表空间将扩展以保存所有这些数据，并且以后不再收缩。它立即释放被占用的磁盘空间
InnoDB表及其索引(删除或截断表时)。每个表及其关联的索引都用.ibd文件被这些DDL操作删除或清空。对象中允许未使用的空间
.ibd要回收的文件优化表语句，当删除大量数据或删除索引时。它支持部分备份
InnoDB表而不是其他表，正如在第3.3.4节“进行部分备份”．它允许对InnoDB表使用表压缩。
一般来说，使用表压缩通过具有ROW_FORMAT =压缩减少表大小，提高备份和恢复性能。然而，作为一种权衡，表压缩可能会增加重做日志的大小，从而减缓增量备份和恢复，以及运用原木操作。看到InnoDB表如何压缩获取详细信息。
避免创建查询不使用的索引。由于索引占用备份数据的空间，不必要的索引会降低备份进程的速度。使用的复制和扫描机制mysqlbackup不要依赖索引来完成它们的工作。)例如，在表的每一列上创建索引通常没有帮助，因为任何查询只使用一个索引。因为每一个都包含主键列InnoDB二级索引，定义由大量或冗长的列组成的主键，或具有相同列的不同排列的多个二级索引会浪费空间。
运用原木阶段
如果将备份数据存储在单独的机器上，并且该机器没有托管数据库服务器的机器那么繁忙，那么可以减轻一些后处理工作(即数据库服务器的后处理工作)运用原木Phase)到那个独立的机器。第5.1.1.2节“为现有备份数据应用日志操作”
在初始备份之后立即执行apply-log阶段(使恢复更快)和将其推迟到恢复之前(使备份更快)之间总是有一个性能权衡。在紧急情况下，恢复性能是最重要的考虑因素。因此，数据越重要，在备份之后立即运行apply-log阶段就越重要。在同一服务器上组合备份和应用程序日志阶段backup-and-apply-log选项，或者执行快速初始备份，将备份数据传输到另一个服务器，然后使用的选项之一执行apply-log阶段第5.1.1.2节“为现有备份数据应用日志操作”．