6

我正在尝试导出我们非常大的 MySQL 数据库（1.6GB - 主要是 BLOB）并导入到新服务器中。我已经解决了大部分问题，最终完成了导入，没有任何错误。使用 MySQL 查询浏览器，我在一张带有 BLOB 图像的表上运行查询并将一个保存到磁盘（使用查询浏览器中的保存图标）。当我尝试打开文件时，我收到“无效的图像格式”错误。哦哦。

使用查询浏览器，我检查了源数据库和最近导入的新数据库上的值。我认为价值观不同。它可能只是编码问题或其他东西。这是我看到的：

源（有效数据）服务器：

FF D8 FF E0    00 10 4A 46    49 46 00 01    01 01 00 60
00 60 00 00    FF DB 00 43    00 08 06 06    07 06 05 08
and so on...

新服务器：

C3 BF C3 98    C3 BF C3 A0    00 10 4A 46    49 46 00 01
01 01 00 60    00 60 00 00    C3 BF C3 9B    00 43 00 08
and so on...

在此示例中，在我的新手眼中，“新”服务器上的数据前面有 3 个字节的额外数据。

然后我使用010 编辑器检查了 sql 转储文件。我找到了这个特定示例的行，这就是我所看到的：

FF D8 FF E0    5C 30 10 4A    46 49 46 5C    30 01 01 01
5C 30 60 5C    30 60 5C 30    5C 30 FF DB    5C 30 43 5C
30 08 06 06    07 06 05 08    and so on...

现在我已经过头了。我看到了模式，我注意到十六进制对 5C 30 看起来与 00 相同，但我不明白为什么。在这一点上，我有一个源服务器即将被擦除，而一个新的服务器恐怕已经导入了损坏的数据。我希望这是某种编码问题，可以通过在 MySQL 中设置全局变量来解决，但我真的不知道。

我还应该提到，当我从源（工作）服务器和新（损坏）服务器保存文件时，损坏文件的文件大小大约大 40%。

我检查了两台服务器上的字符集变量：

SHOW VARIABLES LIKE '%char%'

源服务器：

character_set_client      utf8
character_set_connection  utf8
character_set_database    latin1
character_set_filesystem  binary
character_set_results     utf8
character_set_server      latin1
character_set_system      utf8

新服务器：

character_set_client      utf8
character_set_connection  utf8
character_set_database    latin1
character_set_filesystem  binary
character_set_results     utf8
character_set_server      latin1
character_set_system      utf8

他们是一样的。

4

1 回答 1

6

来自新数据库的损坏数据看起来像是将源数据从 ISO-8859-1 转换为 UTF-8 的结果（例如 U+00FF — ÿ — 是FF前者和C3 BF后者）。

由于 BLOB 没有字符集，字符编码不受服务器变量控制；我怀疑mysqldump正在将您的 BLOB 数据输出到 UTF-8 编码文件（这是默认文件）中，并且通过某种服务器设置和传递给的选项的组合以某种方式对其进行编码mysqldump。

最好的解决方案可能是--hex-blob在导出 BLOB 字段时使用该选项，这将导致如下结果：

INSERT INTO `table` VALUES (0xFFD8FFE0...);
于 2012-12-02T23:42:14.277 回答