我正在从一个mysqldump文件恢复一个30GB的数据库到一个新的服务器上的一个空的数据库。 从转储文件运行SQL时，恢复启动非常快，然后开始变慢和变慢。 个别插入现在需要15+秒。 这些表大部分是MyISAM和一个小InnoDB。 服务器没有其他活动连接。 SHOW PROCESSLIST; 只显示从还原插入（和显示进程列表本身）。
有没有人有任何想法可能导致戏剧性的放缓？
是否有任何MySQLvariables，我可以改变，以加快正在进行的恢复？
有一件事情可能会减慢进程的速度， key_buffer_size是用于索引块的缓冲区的大小。 调整至less30％的内存或重新索引过程可能会太慢。
作为参考，如果您使用InnoDB和外键，也可以禁用外键检查，并在最后重新启用它（使用SET FOREIGN_KEY_CHECKS=0和SET FOREIGN_KEY_CHECKS=1 ）。
此链接显示可以做些什么来加速恢复过程。
http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html
可以把这些命令放在转储文件的顶部
SET @OLD_AUTOCOMMIT=@@AUTOCOMMIT, AUTOCOMMIT = 0; SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS = 0; SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS = 0;
并将这些语句放在转储文件的末尾
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS; SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS; SET AUTOCOMMIT = @OLD_AUTOCOMMIT; COMMIT;
这对我有效。 快乐恢复:-)
我可以想象为什么恢复会逐渐减慢的唯一原因是索引。 调查closures索引，直到结束，然后让它一次完成整个。
如果您有转储文件（DB目录）的物理副本，那么如果新服务器具有相同的MySQL版本，则可以将其复制到新服务器，并且它将正常工作。 这与MyISAM的工作很好，对我来说，我认为这比恢复基于逻辑SQL转储文件的数据更好。
如果你有多个表，你可能会受益于mk-parallel-restore 。
我build议你，
AUTOCOMMIT=0 ， UNIQUE_CHECKS=0 ， FOREIGN_KEY_CHECKS=0 （ AND不要忘了这个变化 ） mysql -u root -pPasss requests < mydb.sql 祝你好运