根本原因是单条insert语句携带blob过大，超出max_allowed_packet限制或连接被服务端断开；需调大该参数、分片插入、手动重连、控制事务大小并匹配innodb日志配置。
分片导入时 blob 数据被截断或报错 mysql server has gone away
根本原因是单条 insert 语句携带的 blob 过大，超出 max_allowed_packet 限制，或连接在长时间执行中被服务端主动断开。不是数据本身有问题，而是传输单元和连接生命周期不匹配。
- 先查当前限制：
SHOW VARIABLES LIKE 'max_allowed_packet';，生产环境建议设为256M或更高（需同步修改 MySQL 配置文件并重启） - 导入前显式设置会话级上限（如果权限允许）：
SET SESSION max_allowed_packet = 268435456; - 更可靠的做法是切分：按行数（如每 50 行）或按累积 BLOB 大小（如累计
LENGTH(blob_col)超过 16MB 就切）生成独立 INSERT，避免单语句撑爆缓冲区 - 别用 mysqldump 的
--skip-extended-insert硬切——它只按行切，对大 BLOB 毫无帮助；要自己控制 INSERT 的字段组合与值批次
Python + pymysql 执行分片导入时连接意外中断
pymysql 默认不自动重连，且长事务中空闲超时（wait_timeout）会静默断连，下次 execute() 直接抛 OperationalError: (2013, 'Lost connection to MySQL server during query')。
- 初始化连接时必须传
autocommit=False和ping=True（触发自动重连），但注意：仅对下一条命令生效，不能覆盖整个批量过程 - 更稳妥的是手动 ping + 重试逻辑：每次分片前调用
conn.ping(reconnect=True)，捕获OperationalError后重新建连再继续 - 避免在循环里反复
commit()——BLOB 写入频繁提交会放大 I/O 压力；建议每 10–50 个分片 commit 一次，同时用conn.begin()显式控事务边界 - 别依赖连接池（如
SQLAlchemy的QueuePool）自动处理超时：它的 recycle 参数对已建立但空闲的连接无效，仍需配合 ping
LOAD DATA INFILE 无法直接加载含 BLOB 的 CSV / TXT
LOAD DATA INFILE 不支持将文本中的十六进制或 base64 编码 BLOB 自动还原为二进制，它只会把那一长串字符当普通字符串插入，导致数据损坏。
- 若源文件是文本格式（如 CSV），必须先用程序解码：读取字段值 →
bytes.fromhex()或base64.b64decode()→ 绑定为bytearray传给cursor.execute() - 想走
LOAD DATA加速？只能导出为 MySQL 原生二进制格式（如用SELECT ... INTO DUMPFILE配合UNHEX()），但该方式不可移植、难调试，线上慎用 - 注意字段分隔符冲突：BLOB 若含
\0、\n或自定义分隔符，会导致LOAD DATA解析错位——此时必须放弃该方案，回归程序分片
事务大小与 InnoDB 日志空间的隐性冲突
大批量 BLOB 插入即使分片，若单次事务包含过多页修改，仍可能触发 innodb_log_file_size 不足，报错 ERROR 1114 (HY000): The table is full（实际是日志满，非磁盘满）。
- 监控关键指标：
SHOW ENGINE INNODB STATUS中的LOG段，看Log sequence number与Log flushed up to差值是否持续接近innodb_log_file_size * innodb_log_files_in_group - 降低单事务 BLOB 总量：例如把“每 50 行”改成“每 20 行”，或按 BLOB 累计大小硬限（如
sum(len(b)) ） - 避免在事务中混入大 UPDATE/DELETE：BLOB 写入本身就会产生大量 undo log，叠加其他操作极易冲垮日志空间
- 这个瓶颈不会在开发机暴露——它高度依赖
innodb_log_file_size配置和磁盘 I/O 延迟，压测时必须用同规格生产配置
事务边界、连接存活、日志容量这三者互相咬合，改一个参数常要同步调另外两个。最容易漏掉的是 innodb_log_file_size 和应用层重连逻辑的配合——光设了 ping=True，却没控制事务粒度，照样在第 37 片断连。
