运行缓慢的 MySql 还原 - 比备份速度慢 10 倍,但仍在运行

Bob*_*way 5 mysql database restore database-restore

我正在将一个大型(~80GB)数据库从它的测试平台移到它的生产环境中。我们正在研究 Windows 服务器。这是我们第一次使用 MySQL,我们仍在学习预期的行为。

我们备份了数据

mysqldump -u root -p --opt [database name] > [database name].sql
Run Code Online (Sandbox Code Playgroud)

这花了大约 3 个小时并创建了一个 45GB 大小的文件。它在一夜之间复制到它的新家,第二天早上,我使用 MySQL Workbench 启动了恢复。根据其日志,它运行

mysql.exe --defaults-file="[路径]\tmpc8tz9l.cnf" --protocol=tcp --host=127.0.0.1 --user=[me] --port=3306 --default-character-set =utf8 --comments --database=[数据库名称] < "H:\[数据库名称].sql"

它正在工作 - 如果我连接到实例,我可以看到数据库和它的一些表。

问题是,它似乎需要永远。我认为它会在与备份相同的 3-4 个时间范围内恢复,可能更快,因为它正在恢复到具有 SSD 驱动器的更强大的服务器上。

但是现在已经过了大约 36 个小时,因为恢复开始了,而且 DB 的大小显然是 30GB。随着它的进行,它似乎变得越来越慢。

现在它已经开始工作了,我不想打断它,所以我想我只需要等待。但供日后参考:这种蜜糖缓慢的恢复速度正常吗?下次我们需要恢复大数据库时,我们可以做些什么来改善问题?

O. *_*nes 7

众所周知,非常大的进口产品很难快速生产。听起来你的导入速度变慢了——每秒处理的行数越来越少——随着它的进行。这可能意味着 MySQL 正在检查每个新行以查看它是否与已插入的行存在键冲突。

您可以做以下几件事:

在开始之前,禁用密钥检查。

   SET FOREIGN_KEY_CHECKS = 0;
   SET UNIQUE_CHECKS = 0;
Run Code Online (Sandbox Code Playgroud)

结束后恢复您的密钥检查。

  SET UNIQUE_CHECKS = 1;
  SET FOREIGN_KEY_CHECKS = 1;
Run Code Online (Sandbox Code Playgroud)

并且,如果您可以将每几千行INSERT操作包装在

   START TRANSACTION;
   INSERT ...
   INSERT ...
   ...
   COMMIT;
Run Code Online (Sandbox Code Playgroud)

您将节省大量磁盘搅动。

请注意,这仅适用于具有数千行或更多行的表。

mysqldump可以创建一个禁用密钥的转储。 https://dev.mysql.com/doc/refman/5.7/en/mysqldump.html#option_mysqldump_disable-keys

mysqldump --disable-keys
Run Code Online (Sandbox Code Playgroud)

相似地,

mysqldump --extended-insert --no-autocommit
Run Code Online (Sandbox Code Playgroud)

将使转储的 sql 文件包含我关于使用事务的建议的一个变体。

在您的情况下,如果您使用过,--opts --no-autocommit您可能会获得最佳转储文件。您已经使用了--opts.