MySQL大字段数据迁移：分批导出与超时设置的实战指南
处理包含大字段（如LONGTEXT或LONGBLOB）的MySQL表迁移，是很多DBA和开发者的“头疼时刻”。默认操作下，导出工具卡死、连接超时、内存溢出等问题层出不穷。今天，我们就来拆解这些问题的根源，并提供一套行之有效的解决方案。
大字段导致 mysqldump 卡死或超时怎么办
直接使用默认参数导出包含大字段的表，mysqldump在读取阶段就卡住，甚至报出MySQL server has gone away的错误，相信不少人都遇到过。问题的本质其实很清晰：单次查询试图拉回的数据量太大了，要么触发了服务端的max_allowed_packet限制，要么就耗尽了客户端的网络超时时间。
所以，关键思路不是一味地“加大超时”，而是要让每次传输的数据量变得可控。这里有三个立竿见影的技巧：
- 加上
--skip-extended-insert参数：这个参数能避免生成包含上百行数据的单条INSERT语句。单条语句变短了，内存压力和网络传输的负担自然就降下来了。 - 强制分批导出：使用
--where="id BETWEEN 1 AND 10000"这样的条件配合脚本循环，比依赖某些不稳定的--limit方式要可靠得多。尤其是在有大字段的场景下，后者依然可能导致单次数据包超载。 - 调低客户端包大小：启动
mysqldump时，别忘了加上--max-allowed-packet=32M这样的参数。这里有个重要细节：这个值必须小于或等于服务端同名参数的值，否则设置是无效的。
用 SELECT ... INTO OUTFILE 导出大字段更稳但有前提
如果说mysqldump是“客户端缓冲”模式，那么SELECT ... INTO OUTFILE就是“服务端直写”模式。它绕开了客户端缓冲，由MySQL服务端直接将结果写入文件，对于处理大字段来说，理论上更加高效稳定。
但是，这个方法有它的“硬性门槛”，用之前必须确认清楚：
- 路径权限问题：目标路径必须是MySQL服务进程有写权限的服务器本地路径。一个常见的误解是，填写了像
/tmp/export.csv这样的路径，却忘了这个/tmp指的是数据库服务器上的目录，而非你操作的本机。 secure_file_priv配置：这个安全变量必须已开启，并且你指定的导出路径必须落在它允许的目录范围内。执行SHOW VARIABLES LIKE 'secure_file_priv'就能看到当前设置。- 适用场景与格式：它通常适合单表批量导出，对于多表或复杂JOIN查询则不太方便。另外，如果字段内容里包含换行符，务必使用
FIELDS ENCLOSED BY '"'进行包裹，否则后续导入时数据列会完全错位。
迁移中 LOAD DATA INFILE 导入失败的典型原因
即便导出环节成功了，导入时也可能因为大字段而“栽跟头”。Packet too large或Incorrect string value这类错误就是典型代表。
要解决它们，得从这几个方面入手：
- 服务端包大小限制：服务端的
max_allowed_packet参数值，必须大于或等于导入文件中单行数据的最大长度。尤其是当LONGBLOB字段存储了Base64编码等内容时，数据体积会膨胀。稳妥起见，可以将其设置为512M甚至更大，并重启mysqld服务使之生效。 - 客户端包大小同步：服务端调大了，客户端也得跟上。在发起
LOAD DATA命令的连接时，同样需要加上--max-allowed-packet=512M参数，否则MySQL客户端库可能会提前截断数据。 - 字符集一致性：
Incorrect string value错误往往源于字符集不匹配。确保导出文件以utf8mb4编码保存，并在LOAD DATA INFILE语句中显式声明CHARACTER SET utf8mb4。
应用层分批同步时，SELECT 大字段的性能陷阱
最后，我们聊聊在应用层（比如用Python、Go写同步脚本）处理大字段时容易踩的坑。如果直接用SELECT *去捞取整张表，大字段会瞬间拖垮网络和内存。
如何优化？记住下面几点：
- 精选查询字段：使用
SELECT id, title, content明确指定需要的字段，远比SELECT *来得高效。少传输几个MB的数据，网络延迟的下降会非常明显。 - 使用游标分页替代
OFFSET：在大表加大字段的场景下，LIMIT 100000, 1000这种写法会先扫描并丢弃前10万行，性能极差。应该改用WHERE id > 100000 ORDER BY id LIMIT 1000这样的“游标”模式。 - 结果集流式处理：不要一次性把所有数据加载到应用内存。在Python中，使用
cursor.fetchmany(100)分批获取；在Go中，利用rows.Next()进行迭代。这才是处理大数据集的正确姿势。
话说回来，最棘手的情况其实是字段内容本身完全不可控——比如用户上传的PDF文件直接存为LONGBLOBfetch操作就可能直接导致内存溢出（OOM），让整个迁移进程崩溃。
