mysqldump导出blob表卡住主因是默认文本模式逐行拼sql致内存溢出或max_allowed_packet截断；应启用--hex-blob和--skip-extended-insert，或改用mydumper、分块hex()导出及load_file()导入。
mysqldump 导出 BLOB 表时卡住或超时
导出含大 BLOB 的表，mysqldump 默认逐行拼接 SQL，遇到几十 MB 的单条记录会吃光内存、触发 OOM 或被 max_allowed_packet 截断，报错类似 MySQL server has gone away 或直接无响应。
关键不是“能不能导”，而是“怎么避免在客户端组装大 SQL”。必须关掉默认的文本模式，改用二进制流式导出：
- 加
--hex-blob：把BLOB转成十六进制字符串，避免转义混乱和编码污染（尤其含二进制 NULL、换行） - 加
--skip-extended-insert：虽然会增大文件体积，但能防止单条 INSERT 过长被服务端拒绝；若数据量极大，可权衡改用--tab直接导出为文本文件 - 调大本地参数：
mysql --max-allowed-packet=1G启动客户端，否则即使服务端设了 1G，客户端仍可能卡在 4MB 默认值
LOAD DATA INFILE 导入 BLOB 数据失败
LOAD DATA INFILE 本身不支持直接读取二进制 BLOB 字段——它只认文本格式。试图把原始图片/视频 dump 成 CSV 再 load，必然乱码或截断。
正确路径是绕过文本层，用 MySQL 的 LOAD_FILE() 函数配合预处理语句注入：
- 确保目标表字段为
MEDIUMBLOB或LONGBLOB，且服务端配置secure_file_priv允许读取对应目录（查SELECT @@secure_file_priv） - 导入语句示例：
INSERT INTO docs (id, content) VALUES (123, LOAD_FILE('/var/lib/mysql-files/report.pdf')); - 注意：
LOAD_FILE()返回NULL多半是权限或路径问题，不是文件内容问题；文件必须由 MySQL 进程可读，不能是用户 home 目录下普通文件
mysqldump --tab 导出大 BLOB 表的实际效果
--tab 看似高效（生成 .sql + .txt 分离），但它对 BLOB 字段默认按字符方式转义写入 .txt，依然会破坏二进制完整性。除非你额外指定 --fields-terminated-by 和 --lines-terminated-by 并配合 HEX() 手动转换，否则不推荐。
更稳妥的做法是放弃纯 SQL 迁移，改用逻辑复制工具或分块导出：
- 用
SELECT id, HEX(content) FROM t WHERE id BETWEEN 1000 AND 2000分批导出十六进制字符串，再用程序 decode 后插入新库 - 若跨版本或跨云迁移，优先考虑
mydumper（支持多线程 + 自动切分 + BLOB 安全转义），比原生mysqldump更可靠 -
mydumper的--chunk-filesize参数能强制按大小拆分，避免单文件过大导致网络传输中断
MySQL 8.0+ 的 data pump（mysqlpump）对 BLOB 支持如何
mysqlpump 是 MySQL 5.7+ 引入的并行导出工具，但它对 BLOB 的处理逻辑和 mysqldump 几乎一致，默认仍走文本序列化。唯一优势是能按表并行、支持压缩，但没解决核心的二进制安全问题。
真正要注意的是它的默认行为变化：
- 默认开启
--compress，但压缩发生在客户端内存中，大BLOB反而更容易触发内存溢出 - 不自动启用
--hex-blob，必须显式加上，否则导出的BLOB在非 UTF8mb4 环境下可能损坏 - 它不支持
--tab模式，所以无法像mysqldump那样“假装”绕过 SQL 层
迁移前务必验证目标库的 collation_connection 和源库一致，否则 HEX() 导出的字符串在导入时可能被错误重编码，解出来就是乱码。
