导入含longblob的4.7G SQL dump遇max_allowed_packet报错求助

核心原因 #

你遇到的问题是因为max_allowed_packet参数需要同时在客户端和服务器端配置，仅在客户端命令行设置无法覆盖服务器的限制；另外如果转储文件中存在单个超过设置值的数据包，也会触发报错。

具体解决步骤 #

• 临时调整服务器端参数（立即生效，重启失效）
  登录MySQL命令行，执行以下命令：

  SET GLOBAL max_allowed_packet = 2 * 1024 * 1024 * 1024; -- 设置为2G
  

  退出当前会话后重新登录，执行SHOW VARIABLES LIKE 'max_allowed_packet';确认参数已生效，之后再重新执行导入命令。

• 永久修改服务器配置（避免重启后失效）
  找到MySQL的配置文件（Linux下通常是/etc/my.cnf或/etc/mysql/my.cnf，Windows下是my.ini），在[mysqld]区块添加或修改：

  max_allowed_packet=2G
  

  保存后重启MySQL服务，再次登录验证参数是否生效。

• 调整导入命令的缓冲区参数
  如果服务器端已设置2G仍报错，尝试在导入命令中增加--net_buffer_length参数优化数据包传输：

  mysql --max-allowed-packet=2048M --net_buffer_length=16384 -uroot -p otobo < /backup/article_data_mime_plain.sql
  

• 处理超大型单个数据包
  若上述操作仍无效，说明转储文件中存在单个longblob数据超过2G（longblob最大支持4G存储），此时可以：

  1. 使用split命令拆分SQL文件（确保拆分点在语句结束的分号后），例如按1G大小拆分：

     split -b 1G /backup/article_data_mime_plain.sql /tmp/otobo_split_
     

     之后逐个导入拆分后的文件：

     mysql -uroot -p otobo < /tmp/otobo_split_aa
     mysql -uroot -p otobo < /tmp/otobo_split_ab
     # 依此类推
     

  2. 若当初导出时未设置足够的max_allowed_packet，重新导出一次：

     mysqldump --max-allowed-packet=2G -uroot -p otobo > /backup/new_article_dump.sql
     

• 优化InnoDB引擎参数（可选）
  如果使用InnoDB引擎，大文件导入可能触发日志空间不足，可调整innodb_log_file_size参数：
  在配置文件的[mysqld]区块添加：

  innodb_log_file_size=2G
  

  保存后重启MySQL服务，再尝试导入。

内容的提问来源于stack exchange，提问作者continius