尝试恢复大于 10 GB 的 sql 转储文件答案

【问题标题】：try to restore a sql dump file larger than 10 GB尝试恢复大于 10 GB 的 sql 转储文件
【发布时间】：2013-11-12 05:34:35
【问题描述】：

我正在尝试恢复一个 13G 大的 sql 转储文件。我第一次在xampp中使用phpAdmin，它说大小太大。然后我使用了大转储，仍然收到错误消息“我无法在 xx.sql 中查找”。我在网上查到，这意味着文件太大。然后我开始使用命令行。 mysql -u 用户名 -p 数据库

有没有办法确保它正常工作？我真的很感谢你的帮助！！ TJ

【问题讨论】：

标签： mysql sql sql-server xampp mysqldump

【解决方案1】：

我恢复类似大小的文件

大约需要 4 到 5 个小时，可能更多取决于您所拥有的键和约束的性质
您可以随时查看进程列表，看看它是否有效。
tail -f mysql 常规日志，并确保它记录任何查询。这是查看它是否工作的最简单方法。 需要注意的是，这会进一步减慢 100% +

【讨论】：

感谢您的快速回复！！我查看了进程列表，命令行程序在进程列表中，但它没有使用任何CPU。
但我不明白你建议的第三个技巧。如何查看日志？谢谢。

【解决方案2】：

使用mysql 命令行客户端恢复文件的另一种方法是这样的：

$ mysql -u username -p database 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2933685
--8<-- snip --8<--

mysql> source location/to/your/dump.sql

source 命令将读取转储文件并将其应用到服务器，就像< 重定向运算符一样，但有两个不同之处：您将看到连续的“x 行受影响”消息滚动，为您提供一些指示这种进展实际上正在发生。这种方法的缺点是，与使用< 重定向的方法不同，如果转储文件中有任何错误，命令行客户端将继续尝试，这并不总是您想要的。不过，这可能是一种可行的方法。

或者...您现在的操作方式，如果您可以在进程列表中看到连接，请检查Sleep 的值。如果该值始终为 0，则表示正在发生某种活动。

【讨论】：

这对我来说效果很好。我有几个数据库，它们都是超过 1GB 的备份。我最大的是12GB。这种方法导入数据非常快，不到 15 分钟。之前，我使用的是 MySQL -u root -p database

【解决方案3】：

试试这个技巧

连接远程MySql数据库后……

生成查询以创建源数据库的表架构、过程和函数
生成查询以查找所有表的所有索引，但源数据库的外键约束除外
生成查询以删除在步骤 2 中找到的所有索引
生成查询以插入源数据库的所有数据
生成查询以创建在步骤 2 中找到的所有索引
按上述顺序将所有查询写入一个 .sql 文件，这是您的新 MySql 备份。使用 LZ4 压缩对其进行压缩。
现在只需使用 MySql 的正常恢复实用程序从该文件恢复 DB。

参考：http://axiomnext.com/blog/how-to-restore-large-mysql-database-faster/

【讨论】：