Question

我是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查看其内容时，我所能看到的只是无法理解的表达式和数据。

Answer 1

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

Answer 2

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

mysqldump db > dump.sql

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

Little-endian 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

Answer 3

您是否尝试过使用notepad ++（或其他编辑器）并将我们转换/保存为UTF-8？

请参阅：notepad++ converting ansi encoded file to utf-8

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

Answer 4

在Windows机器中，请按照上述步骤操作。

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

现在来源你的数据库。

Answer 5

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

tar xf example.sql.gz

Answer 6

在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

问题消失了！

Answer 7

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

Answer 8

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

有时遗留备份文件会对我们起诡计。检查转储文件。

在终端窗口：

~$ cat mybackup.dmp

结果是：

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

停止处理cat命令：

CTRL + C

Answer 9

它必须你提交dump.sql问题。使用Sequel Pro检查你的文件ecoding.It应该是你的dump.sql中的垃圾字符。

Answer 10

如果您没有足够的空间，或者不想在解压缩时浪费时间，请尝试以下命令。

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

别忘了用您的压缩文件名替换Compressed-sqlfile.gz。

.gz还原如果没有我上面提供的命令将无法正常工作。

Answer 11

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

Answer 12

在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完成大文件的工作

Answer 13

你的文件应该只有.sql扩展名，（。zip，.gz .rar）等不支持。示例：dump.sql

Answer 14

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

Answer 15

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

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

Answer 16

我知道原始的发帖人问题已经解决了，但是我是通过Google来到这里的，各种各样的答案最终使我发现我的SQL是用不同于导入默认字符集的默认字符集转储的。我遇到了与原始问题相同的错误，但是由于我们的转储已通过管道传递到另一个MySQL客户端中，因此我们无法采用其他工具打开它并以不同的方式保存它。

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

Answer 17

老但黄金！

在MacOS（Catalina 10.15.7）上，这有点奇怪：我必须将dump.sql重命名为dump.zip，然后，我必须使用finder（！）解压缩它。在终端中，unzip dump.zip或tar xfz dump.sql[or .gz .tar ...]会导致错误消息。

最后，finder将它完全解压缩，之后我可以毫无问题地导入文件。

从SQL转储还原数据库时启用二进制模式

17 个答案: