mysqldump导出blob表卡住或报“mysql server has gone away”根本原因是默认文本模式逐行拼超长insert致客户端oom或被max_allowed_packet截断；须启用--hex-blob、--skip-extended-insert、--quick，并显式指定mysql --max-allowed-packet=2g。
mysqldump导出BLOB表卡住或报MySQL server has gone away
根本不是数据太大“导不出”，而是默认文本模式下，mysqldump把整条含BLOB的记录拼成一条超长INSERT语句，客户端内存扛不住，触发OOM或被max_allowed_packet截断。服务端设了2G没用——客户端默认仍卡在4MB。
必须关闭文本组装逻辑，改走二进制流式路径：
-
--hex-blob：强制BLOB字段以0x...十六进制字符串输出，避免NULL字节、换行符破坏SQL语法 -
--skip-extended-insert：禁用多值INSERT，每行一个INSERT，防止单条语句超限（即使设了--max_allowed_packet=2G） -
--quick（或-q）：逐行从服务端拉取，不缓存整张表到本地内存 - 启动客户端时显式指定包大小：
mysql --max-allowed-packet=2G，否则mysqldump进程自己仍用默认4MB
mysqldump --tab导出BLOB字段为什么还是乱码？
--tab看似高效（生成.sql建表 + .txt数据），但它对BLOB字段默认按字符转义写入.txt，原始二进制会被污染——比如PDF头部%PDF变成\%PDF或直接截断。
除非你额外配合HEX()手动转换，否则别碰--tab导BLOB：
- 导出前需改写查询：
SELECT id, HEX(content) FROM docs，再用--fields-terminated-by控制分隔符 - 导入时不能直接
LOAD DATA INFILE，得用UNHEX()还原：INSERT INTO docs SELECT id, UNHEX(hex_content) FROM ... - 更稳妥的替代是
mydumper，它原生支持BLOB流式导出，不走SQL文本层
LOAD_FILE()导入BLOB返回NULL的常见原因
LOAD_FILE()返回NULL几乎100%不是文件内容问题，而是权限或路径配置失败。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
必须逐项确认：
- 查
SELECT @@secure_file_priv，文件必须放在该路径下（如/var/lib/mysql-files/），不能放/tmp或用户家目录 - MySQL进程要有读权限：
sudo chown mysql:mysql /var/lib/mysql-files/report.pdf - 目标字段类型必须是
MEDIUMBLOB或LONGBLOB，BLOB可能不够用 - 语句里路径必须是绝对路径，且用正斜杠：
LOAD_FILE('/var/lib/mysql-files/report.pdf')，反斜杠或相对路径全无效
为什么BLOB字段本身就在拖慢整个表？
导出只是表象，真正的问题藏在InnoDB存储机制里：BLOB超过768字节后，主体被挪到溢出页，主记录只留20字节指针。这意味着每次SELECT *都要多一次随机I/O去加载溢出页——不是磁盘慢，是CPU和内存在反复拷贝大块二进制。
超过100KB的二进制数据，就该考虑拆出去：
- 业务表只存
file_id和元信息（类型、大小、哈希），BLOB单独放attachments表，用外键关联 - 更彻底的方案是扔到对象存储（S3/OSS），数据库只存URL，彻底解除耦合
- 如果必须留库内，至少把BLOB字段从高频查询的主表中剥离，避免
UPDATE一行INT也要加载几MB BLOB进内存锁行
导出问题背后，往往是表结构设计过载的信号——先想清楚BLOB是不是真该在MySQL里存。
