MySQL blob 转储到制表符分隔文件

发布于 2024-10-20 00:21:29 字数 2221 浏览 4 评论 0原文

我正在迁移 Amazon EC2 中的 MySQL 5.1 数据库,并且我遇到了用于图像存储的 longblob 数据类型的表问题。基本上,迁移后,longblob 列中的数据大小不同,因为字符编码似乎不同。

首先,这是迁移前后的示例:

旧:

x??]]??}?_ѕ??d??i|w?%?????q$??+?

新:

x��]]����_ѕ��d��i|w�%�����q$��+�

我检查了两台机器上的字符集变量,它们是相同的。我还检查了“显示创建表”,它们也相同。客户端的连接方式相同(没有设置名称,或指定字符集)。

这是我使用的 mysqldump 命令(我也在没有 --hex-blob 的情况下尝试过):

mysqldump --hex-blob --default-character-set=utf8 --tab=. DB_NAME

这是我加载数据的方式:

mysql DB_NAME --default-character-set=utf8 -e "LOAD DATA INFILE 'EXAMPLE.txt' INTO TABLE EXAMPLE;"

这是 MySQL 字符集变量(相同):

旧:

+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     | 
| character_set_connection | latin1                     | 
| character_set_database   | utf8                       | 
| character_set_filesystem | binary                     | 
| character_set_results    | latin1                     | 
| character_set_server     | latin1                     | 
| character_set_system     | utf8                       | 
| character_sets_dir       | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+

新:

+--------------------------+----------------------------+    
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     | 
| character_set_connection | latin1                     | 
| character_set_database   | utf8                       | 
| character_set_filesystem | binary                     | 
| character_set_results    | latin1                     | 
| character_set_server     | latin1                     | 
| character_set_system     | utf8                       | 
| character_sets_dir       | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+

我不确定是什么否则尝试能够运行 mysqldump 并使两台计算机上的 blob 数据相同。任何提示将不胜感激。

I am migrating a MySQL 5.1 database in Amazon's EC2, and I am having issues tables with longblob datatype we use for image storage. Basically, after the migration, the data in the longblob column is a different size, due to the fact that the character encoding seems to be different.

First of all, here is an example of before and after the migration:

Old:

x??]]??}?_ѕ??d??i|w?%?????q$??+?

New:

x��]]����_ѕ��d��i|w�%�����q$��+�

I checked the character set variables on both machines and they are identical. I also checked the 'show create table' and they are identical as well. The client's are both connecting the same way (no SET NAMES, or specifying character sets).

Here is the mysqldump command I used (I tried it without --hex-blob as well):

mysqldump --hex-blob --default-character-set=utf8 --tab=. DB_NAME

Here is how I loaded the data:

mysql DB_NAME --default-character-set=utf8 -e "LOAD DATA INFILE 'EXAMPLE.txt' INTO TABLE EXAMPLE;"

Here are the MySQL character set variables (identical):

Old:

+--------------------------+----------------------------+
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     | 
| character_set_connection | latin1                     | 
| character_set_database   | utf8                       | 
| character_set_filesystem | binary                     | 
| character_set_results    | latin1                     | 
| character_set_server     | latin1                     | 
| character_set_system     | utf8                       | 
| character_sets_dir       | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+

New:

+--------------------------+----------------------------+    
| Variable_name            | Value                      |
+--------------------------+----------------------------+
| character_set_client     | latin1                     | 
| character_set_connection | latin1                     | 
| character_set_database   | utf8                       | 
| character_set_filesystem | binary                     | 
| character_set_results    | latin1                     | 
| character_set_server     | latin1                     | 
| character_set_system     | utf8                       | 
| character_sets_dir       | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+

I'm not sure what else to try to be able to run mysqldump and have the blob data be identical on both machines. Any tips would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

你げ笑在眉眼 2024-10-27 00:21:29

这个问题似乎是 mysql 中的一个错误(http://bugs.mysql.com/bug.php?id=27724)。解决方案是不使用 mysqldump,而是为包含 blob 数据的表编写自己的 SELECT INTO OUTFILE 脚本。下面是一个示例:

SELECT
COALESCE(column1, @nullval), 
COALESCE(column2, @nullval), 
COALESCE(HEX(column3), @nullval), 
COALESCE(column4, @nullval), 
COALESCE(column5, @nullval)
FROM table
INTO OUTFILE '/mnt/dump/table.txt' 
FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';

加载数据:

SET NAMES utf8;
LOAD DATA INFILE '/mnt/dump/table.txt'
INTO TABLE table
FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'
(column1, column1, @column1, column1, column1)
SET data = UNHEX(@column1)

这会正确加载 blob 数据。

The issue seems to be a bug in mysql (http://bugs.mysql.com/bug.php?id=27724). The solution is to not use mysqldump, but to write your own SELECT INTO OUTFILE script for the tables that have blob data. Here is an example:

SELECT
COALESCE(column1, @nullval), 
COALESCE(column2, @nullval), 
COALESCE(HEX(column3), @nullval), 
COALESCE(column4, @nullval), 
COALESCE(column5, @nullval)
FROM table
INTO OUTFILE '/mnt/dump/table.txt' 
FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';

To load the data:

SET NAMES utf8;
LOAD DATA INFILE '/mnt/dump/table.txt'
INTO TABLE table
FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n'
(column1, column1, @column1, column1, column1)
SET data = UNHEX(@column1)

This loads the blob data correctly.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文