本节介绍使用 MySQL Enterprise Backup 还原数据库的性能注意事项。这个主题很重要，因为：
恢复操作是备份-恢复周期的阶段，在不同的备份方法之间往往会有很大差异。例如，使用mysqldump备份性能可能是可以接受的，但 mysqldump通常比 MySQL Enterprise Backup 花费更长的时间来进行恢复操作。
恢复操作通常在紧急情况下执行，此时将应用程序或网站的停机时间降至最低至关重要。
恢复操作总是在数据库服务器关闭的情况下执行。
恢复操作主要依赖于低级考虑，例如传输文件的 I/O 和网络速度，以及解压缩数据的 CPU 速度、处理器内核等。
对于可以为还原作业指定的选项组合，请参阅第 13.3 节，“还原操作”。
恢复不同类别的备份数据
恢复部分备份比恢复完整备份花费的时间更少，因为要物理复制的数据更少。有关制作部分备份的信息，请参阅 第 14.8 节，“部分备份和恢复选项”。
恢复压缩备份比恢复未压缩备份需要更多时间，因为解压缩数据所需的时间通常大于通过网络传输较少数据所节省的时间。如果您需要重新安排存储以释放足够的空间来在恢复备份之前解压缩备份，请将管理工作包括在您对所需总时间的估计中。在紧急情况下，在恢复备份数据之前解压缩备份数据所需的时间可能是不可接受的。在数据库服务器上保存压缩备份和未压缩数据。因此，数据越重要，您就越有可能选择不使用压缩：接受较慢、较大的备份以确保恢复过程尽可能快速和可靠。看第 14.6 节，“压缩选项”，了解有关制作压缩备份的信息。
就原始速度或额外存储而言，恢复单个文件备份的解包过程通常并不昂贵。每个文件都直接解压缩到其最终目的地，就像单独复制一样。因此，如果您可以通过使用单文件备份显着加快备份速度或降低其存储要求，那么通常不会涉及恢复时间的权衡。有关制作单文件备份的信息 ，请参阅第 13.5 节，“单文件备份操作” 。
应用日志阶段
有关应用日志阶段的性能注意事项，请参阅应用日志阶段。
网络性能
对于数据处理操作，您可能知道 Unix 套接字在与数据库通信时比 TCP/IP 更快的传统建议。尽管mysqlbackup
命令支持选项
--protocol=tcp、
--protocol=socket和
--protocol=pipe，但这些选项对备份或恢复性能没有显着影响。这些过程涉及文件复制操作而不是客户端/服务器网络流量。由--protocol选项控制的数据库通信是低容量的。例如，mysqlbackup通过数据库连接获取数据库参数信息，但不获取表或索引数据。
并行恢复
mysqlbackup可以利用现代多核 CPU 和操作系统线程来并行执行备份操作。请参阅 第 14.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一旦系统iowait
值达到大约 20%
，就不要增加读取或写入线程的数量
。