【问题标题】:Importing large sql file to MySql via command line通过命令行将大型 sql 文件导入 MySql
【发布时间】:2013-10-20 21:29:36
【问题描述】:

我正在尝试通过 Ubuntu 中的命令行将大约 300MB 的 sql 文件导入 MySql。我用过

source /var/www/myfile.sql;

现在它显示了看似无限的行:

Query OK, 1 row affected (0.03 sec)

但是它现在已经运行了一段时间。我之前没有导入过这么大的文件,所以我只想知道这是否正常,如果进程停止或有一些错误,会出现在命令行中还是会无限期地继续?

谢谢

【问题讨论】:

  • 它将继续运行脚本中的每个查询,直到客户端崩溃或 mysql 死机,或者它用完要处理的查询。
  • 如果客户端崩溃或 mysql 死机,我会在命令行中看到此错误消息还是它只是无限继续并“出现”就像它正在运行一样。我只是想知道,如果导入拖了几个小时,我不会浪费我的时间不重新启动进程
  • 如果客户端崩溃,您将返回 shell 提示符。
  • 如果服务器崩溃...实际上不确定。客户端很可能会反复尝试重新连接并开始吐出错误而不是成功的查询通知。

标签: mysql ubuntu


【解决方案1】:

您可以像这样使用标准输入导入 .sql 文件:

mysql -u <user> -p<password> <dbname> < file.sql

注意:<-p><password>之间不能有空格

参考:http://dev.mysql.com/doc/refman/5.0/en/mysql-batch-commands.html

建议编辑注意事项:建议编辑略微更改了此答案以使用内联密码参数。我可以将它推荐给脚本,但您应该知道,当您直接在参数 (-p<password>) 中写入密码时,它可能会被 shell 历史缓存,向任何可以读取历史文件的人透露您的密码。而-p 要求您通过标准输入输入密码。

【讨论】:

  • 哦,我明白了,但是我使用的方法是否也可以,或者是错误的
  • 对于您的方法,请参见此处的参考:dev.mysql.com/doc/refman/5.0/en/mysql-batch-commands.html
  • 什么.. 4GB 需要 4-5 分钟?我在具有 4 核和 7GB RAM 的 Windows azure VM 上运行 vanilla mysql 安装。花了30分钟,还在继续。你觉得这里有什么问题吗?
  • 好吧,基本上我查了一些信息,研究了一些关于 mysql 调优的信息。我将 innodb 的缓冲池大小增加到 12G,并且与其他一些设置一起,我注意到显着的速度改进。我的导入过程从 20 多个小时减少到 1 小时,这很棒:)
  • 不起作用。因为我的文件是 700 GB!在不断超时的托管服务器上。但这是正确的方向。我获得了 SSH 访问权限,然后获得了 unix split 文件。 Vim 仍然太慢,所以我使用 headtail 来确保我的拆分是可以接受的。我还必须cat 附加标头信息/变量。然后运行命令,它工作了。我在 45 分钟内完成了我花了 9 个小时手工完成的工作!谢谢你马丁!
【解决方案2】:

关于导入大文件所花费的时间,最重要的是需要更多时间,因为 mysql 的默认设置是“autocommit = true”,您必须在导入文件之前将其设置为关闭,然后检查导入如何像 gem 一样工作。 .

首先打开 MySQL:

mysql -u root -p

然后,您只需要执行以下操作:

mysql>use your_db

mysql>SET autocommit=0 ; source the_sql_file.sql ; COMMIT ;

【讨论】:

  • 这太酷了。我喜欢。也是一条信息。使用以下命令将所有 sql 文件收集到一个 sql 文件中: cat *.sql >> all_data.sql 这非常有用。我现在正在导入 3.5G 文件 :) 不要忘记表必须是 MyIsam。
  • 表 xxx 不退出...为什么
  • 导入完成后自动提交不应该返回SET autocommit=1 ;吗?
  • 不再必须是 MyISAM 表。这是有关独特表/等的更多信息和其他速度调整的手册页dev.mysql.com/doc/refman/5.6/en/…
  • 嗨...如何跳过错误,以便在错误后继续导入...使用 Force ?如何集成 SET autocommit=0 ;源 the_sql_file.sql ;犯罪 ; ? - 力量; ?
【解决方案3】:

+1 到@MartinNuc,你可以在批处理模式下运行mysql 客户端,然后你就不会看到长长的“OK”行了。

导入给定 SQL 文件所需的时间取决于很多因素。不仅是文件的大小,还有其中的语句类型、你的服务器服务器有多强大,以及同时运行的其他东西有多少。

@MartinNuc 说他可以在 4-5 分钟内加载 4GB 的 SQL,但我已经运行了 0.5GB 的 SQL 文件,并且在较小的服务器上需要 45 分钟。

我们无法真正猜测在您的服务器上运行 SQL 脚本需要多长时间。


你的评论,

@MartinNuc 是正确的,您可以选择让 mysql 客户端打印每条语句。或者您可以打开第二个会话并运行 mysql> SHOW PROCESSLIST 以查看正在运行的内容。但您可能更感兴趣的是“完成百分比”数字或完成剩余语句所需的估计时间。

对不起,没有这样的功能。 mysql客户端不知道运行后面的语句需要多长时间,甚至不知道有多少。因此它无法对完成所需的时间给出有意义的估计。

【讨论】:

  • 感谢Bill 的回复,Martin 提到的命令是否提供某种进程显示或什么?我现在无法真正测试,因为我必须取消当前的导入。
  • mysql --verbose 查看每个命令。参考文献中提到dev.mysql.com/doc/refman/5.0/en/mysql-batch-commands.html
  • 比尔你可以使用管道视图实用程序获得百分比完成功能......例如sudo pv -i 1 -p -t -e DB.sql | mysql -uDB_USER -p DBANAME
  • @abhi,这是一个很棒的提示!它假设 DB.sql 文件中的每条语句都接近相同的成本,但在大多数情况下这并不是一个糟糕的假设。
  • @abhi,除了我经常压缩我的 .sql 文件,所以我必须知道未压缩的大小才能获得进度条:bunzip2 DB.gz.bz2 | pv -i 1 -p -t -e -s 2758819477 | mysql ...
【解决方案4】:

我用于大型 sql 恢复的解决方案是 mysqldumpsplitter 脚本。我将我的 sql.gz 拆分为单独的表。然后加载 mysql workbench 之类的东西并将其处理为恢复到所需的模式。

这是脚本 https://github.com/kedarvj/mysqldumpsplitter

这适用于较大的 sql 恢复,我使用的一个站点上的平均是 2.5gb sql.gz 文件,未压缩 20GB,完全恢复后约 100Gb

【讨论】:

    【解决方案5】:

    通过命令行将大型 sql 文件导入 MySql

    1. 第一次下载文件。
    2. 在家中粘贴文件。
    3. 在终端中使用以下命令(CMD)
    4. 语法: mysql -u 用户名 -p 数据库名

    示例: mysql -u root -p aanew

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2011-09-30
      • 2012-12-19
      • 2013-01-28
      • 2017-06-15
      • 2015-11-25
      • 2021-08-04
      • 2016-08-06
      • 2016-11-29
      相关资源
      最近更新 更多