在Windows中导入包含二进制BLOB的大型MySQL转储文件时出错
我试图从我的托pipe公司导入一个MySQL转储文件到我的Windows开发机器中，而且我遇到了问题。
我从命令行导入这个，我得到一个非常奇怪的错误：
ERROR 2005（HY000）3118行：未知的MySQL服务器主机╩╖* dd╦h h ^“”π╩╩╪╪+ + +▼▼</s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s></s> 1100î7æ▌X█XE.ºΓ[;╦ï♣Ìμ♂º╜┤║].♂┐φ9dë╟█'╕ÿG∟═0à¡ú♦╥↑ù♣♦''╔NÑ'（11004）
我附上截图，因为我假设二进制数据将会丢失…
我不是很确定问题是什么，但是两个潜在的问题是文件的大小（2Gb），这个大小不是非常大，但也不是很小，另一个是这些表中有很多JPG格式的文件（这就是为什么文件大部分是2Gb的原因）。
另外，这个转储是在一台Linux机器上进行的，我将它导入到Windows中，不确定这是否会增加问题（我理解它不应该）
现在，二进制垃圾是为什么我认为文件中的图像可能是一个问题，但我已经能够从同一个托pipe公司导入类似的转储，所以我不知道可能是什么问题。
此外，试图看看这个文件（特别是3118行）是不可能的，因为它的大小（我不太喜欢Linux命令行工具，如grep，sed等）。
该文件可能已损坏，但我不确定如何检查它。 我下载的是一个.gz文件，我用WinRar“testing”了一下，它说这看起来好（我假设gz有某种CRC）。 如果你能想出一个更好的方法来testing它，我很乐意尝试。
任何想法可能会发生什么/如何克服这个错误？
我并不特别关注这些数据，因为我只是想把它作为开发的一个副本，所以如果我必须丢失一些logging，那么只要模式保持完美的声音，我就可以。
谢谢！
丹尼尔
为此我总是使用mysqldump --hex-blob 。
使用此开关重新转储编码blob的数据库，它将工作。
您可以尝试使用Windows mysql客户端IDE（如sqlyog或mysqlpipe理员）来导入它。 它为我工作过一次。
您不一定需要使用–hex-blob选项。 我刚刚解决了这个问题，我自己的问题是，我需要将–max_allowed_packet设置为足够大的值，以容纳我将加载的最大数据blob。 您的恢复命令应该如下所示：
mysql -u user -h hostname --max_allowed_packet=32M dbname < dumpfile.sql
如果使用–hex-blob选项，则将显着增加备份的大小 – 为2或更大。 注意：要恢复使用上述命令恢复的相同数据，需要在my.ini（cnf）中设置–max_allowed_packet = 64M并在命令行上重新启动服务器AS WELL AS将其设置为64M，以恢复创build的转储–hex-blob选项。
由于文件很大，所以仍然可能会有问题，所以请确保将max-allowed-packet设置为某个较高值（参数为mysql命令）。
从Linux服务器中恢复包含二进制数据的转储文件时，出现类似的问题。 错误类似于ERROR 1064 (42000) at line 551: You have an error in your SQL syntax;
这个转储文件可以成功导入到Linux服务器，但不是Windows。
我已经尝试使用--hex-blob选项和--max_allowed_packet ，甚至用pipe道而不是.sql文件传输数据，但没有运气。
我终于通过使用MySQL Workbench解决了这个问题，生成的命令就像
Running: mysql.exe --defaults-file="c:\users\admini~1\appdata\local\temp\tmp1fzxkx.cnf" --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=platform < "E:\\direcotory\\dump.sql"
然后我尝试--default-character-set=utf8 ，它的工作。 希望这会帮助别人。