从 SQL 转储恢复数据库时启用二进制模式答案

【问题标题】：Enable binary mode while restoring a Database from an SQL dump从 SQL 转储恢复数据库时启用二进制模式
【发布时间】：2013-06-14 01:08:00
【问题描述】：

我对 MySQL 非常陌生，并且正在 Windows 上运行它。我正在尝试从 MySQL 中的转储文件恢复数据库，但出现以下错误：

$ >mysql -u root -p -h localhost -D database -o < dump.sql
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'SQLite format 3'.

我尝试将--binary-mode 放入ini 文件中，但仍然出现同样的错误。我该怎么办？请帮忙。

更新

正如尼克在他的评论中建议的那样，我尝试了$ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sql，但它给了我以下ERROR at line 1: Unknown command '\☻'. 这是一个 500 Mb 的转储文件，当我使用 gVIM 查看其内容时，我只能看到无法理解的表达式和数据。

【问题讨论】：

mysql -u root -p -h localhost -D 数据库 --binary-mode -o
在第 1 行给出 ERROR: Unknown command '\☻'。
我收到了这个错误，但是得到了一个新的 MySQL 转储并尝试重新导入，它工作正常。我们的 MySQL 转储分为两个压缩部分，必须连接然后解压缩。我认为最初的解压缩被中断，导致.sql 文件带有奇怪的字符和编码。第二次尝试效果很好。

标签： mysql database mysqldump database-restore

【解决方案1】：

解压文件，然后重新导入。

【讨论】：

你的意思是先压缩再解压缩？
这对我来说是这样的，解压缩db.sql.gz，你会得到db.sql，再次重命名为db.sql.gz，不要压缩它，重命名它，然后再次解压缩到 db.sql，现在您将获得要导入的正确文件。
@MotsManish 认真的吗？我以为这是个笑话。我会试一试，看看是否有效。
掌心?‍♀️?‍♀️?‍♀️?‍♀️
如何解压 db 文件？

【解决方案2】：

我在 Windows 恢复转储文件时遇到了同样的问题。我的转储文件是使用 windows powershell 和 mysqldump 创建的，例如：

mysqldump db > dump.sql

问题来自powershell的默认编码是UTF16。为了更深入地了解这一点，我们可以使用 GNU 的“文件”实用程序，并且存在一个 Windows 版本here。
我的转储文件的输出是：

小端 UTF-16 Unicode 文本，行很长，带有 CRLF 行终止符。

然后需要转换编码系统，有各种软件可以做到这一点。例如在 emacs 中，

M-x set-buffer-file-coding-system

然后输入所需的编码系统，例如utf-8。

以后，为了获得更好的 mysqldump 结果，请使用：

mysqldump <dbname> -r <filename>

然后输出由mysqldump自己处理，而不是powershell的重定向。

参考：https://dba.stackexchange.com/questions/44721/error-while-restoring-a-database-from-an-sql-dump

【讨论】：

mysqldump -r 任何使用 Windows 或 DOS 系统的人，这是解决方案。 UTF-8 文件转换是一种干扰。使用 -r 选项，它将输出定向到文件名并处理 Windows 放入文件的 CRLF 回车换行符 (\r\n)，这就是问题所在。感谢您提供出色的解决方案！
实际上，我在 Powershell 中创建文件后通过使用 Notepad++ 将生成的文件转换为 UTF-8 解决了这个问题。
这个答案，如果我没有深入研究，会节省我数小时寻找正确答案的时间。希望我能多次投票。
我和@PeterMajeed 做了同样的事情。 NotePad++ 的快速转换和保存功能让我可以恢复现有文件
这对我来说是最好的答案，不知道为什么接受的答案比这个有 200 多票

【解决方案3】：

在Windows机器上，请按照前面的步骤。

在记事本中打开文件。
点击另存为
选择编码类型 UTF-8。

现在获取您的数据库。

【讨论】：

这对我来说适用于通过 Powershell 运行 mysqldump 创建的 SQL 备份文件。 Poweshell 输出为 UTF-16。更改为 UTF-8 解决了这个问题，并允许我从备份文件中恢复我的 detabase。

【解决方案4】：

使用 Tar 归档工具提取文件。你可以这样使用它：

tar xf example.sql.gz

【讨论】：

这就是我的答案。起初，我压缩了 .sql.gz 文件，导致导入时出现“二进制”错误。原来文件是 tar/gzip 压缩的，所以我必须先 tar xvf 文件，然后它让我导入它。

【解决方案5】：

在 Windows PowerShell 上运行 mysqldump 后，我遇到过一次错误：

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF > db_objects.sql

我所做的就是把它改成这个（管道而不是 Set-Content）：

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF | Set-Content db_objects.sql

问题就解决了！

【讨论】：

我得到 mysqldump: Got errno 32 on
看看这个帖子能不能帮到你：stackoverflow.com/questions/22288271/…
谢谢。问题是我在旧的 mysql 服务器上使用旧版本的 phpmyadmin 导出了数据库。不知道为什么，但一半的数据库是以明文形式导出的，另一半是 gzip 格式的。

【解决方案6】：

如果你没有足够的空间或者不想浪费时间解压，试试这个命令。

gunzip < compressed-sqlfile.gz | mysql -u root -p

不要忘记将compressed-sqlfile.gz 替换为您的文件名。

如果没有我上面提供的命令，.gz restore 将无法工作。

【讨论】：

你应该在命令后面加上database_name，这样才会将sql文件导入到那个数据库，否则会报错。例如：gunzip < compressed-sqlfile.gz | mysql -u root -p your_database_name

【解决方案7】：

您是否尝试过在记事本++（或其他编辑器）中打开并将我们转换/保存为 UTF-8？

见：notepad++ converting ansi encoded file to utf-8

另一种选择可能是使用 textwrangle 打开文件并将其另存为 UTF-8：http://www.barebones.com/products/textwrangler/

【讨论】：

谢谢。这对我有用。在 NotePad++ 中打开文件。编码 > 转换为 UTF 8。
另请注意，在使用 utf-8 编码“另存为”现有 .sql 文件后文件大小的显着变化！几乎是给定文件的一半大小。在我的情况下，mysqldump 是使用 Windows Power Shell 获取的，该程序弄乱了编码。

【解决方案8】：

可能是您的 dump.sql 在文件开头有垃圾字符或开头有一个空行。

【讨论】：

【解决方案9】：

你的dump.sql文件一定有问题。使用Sequel Pro检查你的文件编码。它应该是你的dump.sql中的垃圾字符。

【讨论】：

【解决方案10】：

我遇到了同样的问题，但发现转储文件实际上是 MSSQL Server 备份，而不是 MySQL。

有时旧备份文件会欺骗我们。检查您的转储文件。

在终端窗口上：

~$ cat mybackup.dmp

结果是：

TAPE??G?"5,^}???Microsoft SQL ServerSPAD^LSFMB8..... etc...

停止处理 cat 命令：

CTRL + C

【讨论】：

【解决方案11】：

zcat /path/to/file.sql.gz | mysql -u 'root' -p your_database

【讨论】：

【解决方案12】：

您尝试导入的文件是一个 zip 文件。解压缩文件，然后再次尝试导入。

【讨论】：

【解决方案13】：

linux下使用 gunzip 解压缩文件编辑您的解压缩 sql 文件使用

vi unzipsqlfile.sql

用 esc dd 删除第一个二进制行使用 esc shift g 转到文件底部用 dd 删除最后一个二进制行保存文件 esc x: 然后重新导入mysql：

mysql -u 用户名 -p new_database

我使用来自 jetbackup cpanel mysql 备份的 20go sql 文件执行该操作。耐心等待 vi 处理大文件

【讨论】：

【解决方案14】：

您的文件只能是 .sql 扩展名，(.zip, .gz .rar) 等将不支持。示例：dump.sql

【讨论】：

【解决方案15】：

您可以使用它来修复错误：

zcat {address_sql_database(.tar.gz)} | mysql -u root -p {database_name} --binary-mode

【讨论】：

为什么？请解释它是如何回答这个问题的。

【解决方案16】：

我知道最初的海报问题已经解决，但我是通过 Google 来到这里的，各种答案最终让我发现我的 SQL 被转储的默认字符集与用于导入它的字符集不同。我得到了与原始问题相同的错误，但由于我们的转储被传送到另一个 MySQL 客户端，我们无法使用另一个工具打开它并以不同的方式保存它。

对我们来说，解决方案是--default-character-set=utf8mb4 选项，既可用于mysqldump 的调用，也可用于通过mysql 导入它的调用。当然，对于面临相同问题的其他人来说，参数的值可能会有所不同，重要的是保持相同，因为服务器（或工具）的默认设置可能是任何字符集。

【讨论】：

您介意分享您编写的整个字符串吗？因为我和你的情况一样。我仍然不确定为什么它对我不起作用。它在同一台服务器上，尝试使用mysqldump -uUSER -p user_db | gzip > user_db_$(date +"%Y%m%d_%H%M").sql.gz 暂存网站，然后尝试使用gunzip -c user_db_datetime.sql.gz | mysql -uUSER -p user_db 导入它
我们的字符串对您没有帮助，因为它是各种自定义设置的巨大集合。您描述您的情况的方式，我的回答不适用：我的问题源于转储计算机/连接的设置与恢复设置不同，因此我们需要指定默认字符集以强制它们相同。跨度>

【解决方案17】：

旧但黄金！

在 MacOS（Catalina 10.15.7）上有点奇怪：我不得不将我的dump.sql 重命名为dump.zip 之后，我不得不使用 finder(!) 来解压缩它。在终端中，unzip dump.zip oder tar xfz dump.sql[or .gz .tar ...] 导致错误消息。

最后，finder 已经完全解压了，之后我就可以毫无问题地导入文件了。

【讨论】：