确认是否为 max_allowed_packet 超限需先查日志是否有“Packets larger than max_allowed_packet are not allowed”，再执行 SHOW VARIABLES LIKE 'max_allowed_packet' 对比操作数据大小；服务端须在 [mysqld] 段配置并重启，客户端也需单独设置对应参数，避免OOM和复制延迟，推荐起步64M–100M。
怎么确认真是 max_allowed_packet 超限导致失败
报错里出现 Got a packet bigger than 'max_allowed_packet' 或 MySQL server has gone away，不能直接开调；先查日志有没有紧跟着 Packets larger than max_allowed_packet are not allowed —— 这才是铁证。再执行 SHOW VARIABLES LIKE 'max_allowed_packet';，看返回值（单位是字节），对比你正在操作的数据：比如一条含 500KB JSON 的 INSERT、一个 8MB 的 base64 字符串字段、或 mysqldump 导出的单行超长 SQL —— 这些都可能突破默认 4MB 限制。
服务端改配置必须写进 [mysqld] 段并重启
SET GLOBAL max_allowed_packet = 536870912; 只对当前运行实例生效，已有连接不继承，重启后清零；真正落地得改配置文件：
- Linux 常见路径：
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf - Windows 查
my.ini（常在C:\ProgramData\MySQL\） - 在
[mysqld]段下加一行：max_allowed_packet = 512M（支持K/M/G后缀，比硬写 536870912 更安全） - 改完必须重启服务：
sudo systemctl restart mysql（Ubuntu/Debian）或sudo service mysqld restart（CentOS/RHEL） - 主从架构下，从库的
[mysqld]段也得同步改，否则大事务或LOAD DATA会中断复制
客户端不配，服务端设再大也没用
服务端设成 512M，不代表你用 mysql 命令行、Python 的 pymysql 或 JDBC 就能发 512M 的包——各客户端有独立缓冲区限制：
-
mysql命令行：在~/.my.cnf的[client]段加max_allowed_packet = 512M，或启动时加参数mysql --max-allowed-packet=536870912 -u root -p - Python
mysql-connector：初始化连接时显式传参max_allowed_packet=536870912 - JDBC：URL 中加
&maxAllowedPacket=536870912（注意单位是字节） -
mysqldump和mysqlimport：它们是客户端工具，同样要加--max-allowed-packet=536870912，否则导出/导入大表仍报错
别盲目设过大，OOM 和复制延迟风险真实存在
推荐起步值 64M–100M，按实际场景阶梯上调；设到 1G 虽然语法合法，但 MySQL 在处理单个超大包时会一次性分配对应内存，容易触发 OOM；主从复制中，大包还会阻塞 relay log 写入，拖慢从库追赶速度。另外，max_allowed_packet 不是“上传文件大小上限”，它管的是 SQL 语句、结果集、BLOB 字段、LOAD DATA 行数据等传输打包的尺寸——真正要传大文件，该走 LOAD DATA INFILE + 服务端文件权限，而不是拼成超长字符串塞进 SQL。
