旧表BLOB字段导出来是乱码或者空值？这种情况其实挺常见的。但先别急着怀疑数据本身——数据很可能完好无损，只是你没有找到正确的打开方式。

要验证数据是否真实存在且没有损坏，最直接的办法：在旧库跑一句SELECT LENGTH(blob_column) FROM old_table WHERE id = 123，看看返回值是不是零。Oracle环境下，建议用DBMS_LOB.GETLENGTH；SQL Server则用DATALENGTH——这俩函数比普通的LEN靠谱得多。

如果长度正常，导出来却是空的，那就得留个心眼了：大概率是应用层做了加密或者Base64封装。此时需要去翻一翻旧代码，重点检查有没有encodeBase64或encryptImage这类调用。

确认旧表 BLOB 字段的存储格式和可读性

直接SELECT出来是乱码或空值？先验证数据是否真实存在且未损坏。很多旧系统用的是LONG RAW、IMAGE（SQL Server 2005之前的版本），或是未指定字符集的BLOB，这些在新库中很容易出现不识别的情况。实操建议就是上面说的那几步：查长度、选对函数、翻代码。

INSERT … SELECT 迁移时必须绕过客户端字节流限制

别指望一句INSERT INTO new_table (id, image_data) SELECT id, blob_column FROM old_table就能搞定问题。大部分JDBC或ODBC驱动默认把BLOB当字符串处理，结果就是触发截断、编码转换，甚至直接内存溢出。

• MySQL：连接参数必须带上useServerPrepStmts=true&allowLoadLocalInfile=true，然后用LOAD_FILE()配合临时文件（不过这个只能在同一台机器上用）。
• PostgreSQL：试试pg_dump --column-inserts导出，加上--inserts参数，再手动替换lo_import调用。
• 通用稳妥方案：改用服务端脚本。比如Python配合psycopg2或cx_Oracle，逐行fetch后，再加上cursor.setinputsizes(image_data=psycopg2.BINARY)显式声明二进制类型。到这儿，问题基本就解决了。

新表字段类型与 NULL 约束必须匹配业务实际

数据迁移完了，有些图片打不开？原因大概率是：新表定义的是NOT NULL，但旧数据里有空BLOB（比如EMPTY_BLOB()或0x）。或者是字段类型用错了——比如PostgreSQL里把BYTEA写成TEXT，导致二进制数据被自动转义损坏。

• Oracle：新表用BLOB，别用BFILE——后者依赖文件系统路径，容易出问题。
• MySQL：用LONGBLOB，而不是MEDIUMBLOB。老扫描仪的图片经常超过16MB，用MEDIUMBLOB可能不够。
• 迁移前跑一次校验：先查一下SELECT COUNT(*) FROM old_table WHERE blob_column IS NULL OR DBMS_LOB.GETLENGTH(blob_column) = 0。如果结果不为0，那就得在INSERT里加上COALESCE(blob_column, EMPTY_BLOB())来处理空值。

迁移后校验不能只看行数一致

行数对上了，但图片缩略图全是黑的？说明二进制内容被静默篡改了。这种情况通常是因为客户端设了character_set_client=utf8mb4，结果去插二进制数据时，MySQL自动尝试UTF-8解码然后报错回退，最后存入乱码。

• 抽样比对MD5：Oracle环境用SELECT DBMS_CRYPTO.HASH(blob_column, 2) FROM old_table WHERE id = 123来比对新旧表对应记录。
• PostgreSQL：用md5(decode(image_data::text, 'escape'))，注意要用escape模式。
• 最简验证：直接用hex()或TO_HEX()取前32字节做字符串比对。这样比完整哈希快得多，而且足够暴露编码问题。

真正麻烦的是跨数据库迁移，比如从Oracle迁移到PostgreSQL。不同数据库对BLOB的chunk处理逻辑差别挺大，哪怕字节看起来一致，某些驱动可能多写了几个x00。这种场景下，最好在应用层加一层CRC32校验字段——别只信数据库层面报的“迁移成功”。