MySQL 5.7到8.0单表迁移后blob列显示十六进制异常的解决咨询

• 异常本质：原默认导出流程未显式约束字符集和BLOB转义规则，跨版本导入时，MySQL 8.0的会话默认字符集与导出文件编码不匹配，导致原本代表BLOB二进制内容的0x十六进制字面量，被当成普通字符串存入了BLOB列。
• 注意：观察到的int(10) unsigned类显示长度差异，是MySQL 8.0移除整型显示长度元数据的正常变更，不影响实际存储和计算逻辑，无需额外处理。

正确导出操作（在MySQL 5.7源服务器执行） #

在原有导出命令基础上增加两个必选参数，完全匹配迁移链路的字符集与BLOB处理规则：
mysqldump --default-character-set=latin1 --hex-blob db_name table_name > table_name.sql

• --default-character-set=latin1：强制导出全流程使用与源、目标库一致的字符集，避免SQL文件被默认字符集转码导致解析错乱
• --hex-blob：将所有BLOB、二进制类型字段导出为跨版本兼容的十六进制字面量格式，不会因不同版本的字符串转义规则差异被误判为普通文本

正确导入操作（在MySQL 8.0目标服务器执行） #

导入时同样显式指定会话字符集，避免MySQL 8.0默认的utf8mb4字符集与导入文件编码不匹配：
mysql --default-character-set=latin1 -u username -p db_name < /path/to/table_name.sql

已导入错误数据的快速修复 #

如果已经导入了异常数据，可直接对BLOB列执行转换，将存储为字符串的0x十六进制值还原为原始二进制内容：

-- 对每个异常BLOB列分别执行
UPDATE table_name 
SET bio = UNHEX(REPLACE(bio, '0x', '')) 
WHERE bio LIKE '0x%';

UPDATE table_name 
SET rawbio = UNHEX(REPLACE(rawbio, '0x', '')) 
WHERE rawbio LIKE '0x%';

校验方法 #

导入或修复完成后，通过两种方式交叉验证数据正确性：

• 直接查询BLOB列，确认返回的是原始可打印文本，而非0x开头的字符串：SELECT bio, rawbio FROM table_name LIMIT 10;
• 用十六进制函数交叉校验内容一致性：SELECT HEX(bio) FROM table_name LIMIT 1; 返回的十六进制值应与原始文本的编码结果匹配（比如原始文本以<p>开头，返回值开头应为3C703E）

内容的提问来源于stack exchange，提问作者Stephen McDonald