直接原因是客户端或服务端收到的数据包超过max_allowed_packet限制；该限制作用于单次通信包，非总传输量，常见于含长文本、JSON或Base64的批量INSERT语句，触发Packet Too Large错误。
MySQL批量插入失败，直接原因是客户端或服务端收到的数据包超过了 max_allowed_packet 限制——不是SQL写错了，也不是权限问题，就是“包太大被拒收”。
为什么批量插入容易触发 Packet Too Large 错误
批量插入（比如 INSERT INTO ... VALUES (...), (...), (...)）会把多行数据拼成一条语句发给服务端。数据量一上来，整条语句的字节长度就可能远超默认值（MySQL 8.0+ 默认是 64MB，但很多旧部署或 Docker 镜像仍沿用 4MB）。尤其当字段含长文本、JSON 或 Base64 图片时，单条语句轻松突破几 MB。
- 错误典型表现：
Packet for query is too large (3456888 > 1048576)或Got a packet bigger than 'max_allowed_packet' bytes - 注意：这个限制作用于「单次通信包」，不是总传输量。哪怕你分 10 次 insert，只要某一次单条语句超过阈值，照样报错
- Java 应用常见异常：
com.mysql.cj.jdbc.exceptions.PacketTooBigException，括号里两个数字分别是实际大小和当前允许上限（单位字节）
如何快速验证并临时调大 max_allowed_packet
先确认当前值，再用 SET GLOBAL 快速生效（无需重启），适合开发/测试环境紧急修复：
- 登录 MySQL 后执行：
SHOW VARIABLES LIKE 'max_allowed_packet';—— 查看当前字节数（例如4194304= 4MB） - 执行：
SET GLOBAL max_allowed_packet = 268435456;—— 设为 256MB（必须用字节，不能写256M） - 立即生效，但只对后续新连接起作用；已存在的连接仍用旧值，需重连
- 该设置在 MySQL 重启后丢失，仅作临时排查用
永久生效必须改配置文件，且要分清 [mysqld] 和 [client]
只改服务端不改客户端，或者只改客户端不改服务端，都可能出问题。比如用 mysql --max_allowed_packet=512M -u root -p 连接，但服务端仍是 4MB，插入大包照样失败。
- 服务端配置（影响所有客户端请求）：在
my.cnf（Linux）或my.ini（Windows）的[mysqld]段下加一行：max_allowed_packet = 512M - 客户端配置（影响 mysql 命令行、某些驱动行为）：在同配置文件的
[client]或[mysql]段下加：max_allowed_packet = 512M - 改完必须重启 MySQL 服务（
systemctl restart mysqld或 Windows 服务管理器） - 注意：配置文件中支持
M/G单位，命令行SET不支持
应用端也要同步检查驱动参数
即使服务端和配置文件都调大了，Java 的 JDBC URL、Python 的 mysql-connector-python 或 Node.js 的 mysql2 仍可能自带默认限制。
- JDBC URL 示例：
jdbc:mysql://localhost:3306/db?maxAllowedPacket=536870912（单位字节） - Python mysql-connector：初始化时传参
connection.MySQLConnection(..., connection_timeout=30, autocommit=True, max_allowed_packet=536870912) - Node.js mysql2：在连接配置里加
maxAllowedPacket: 536870912 - 漏掉这一环，应用层发出去的包在到达 MySQL 前就被驱动截断了
真正麻烦的点不在“怎么设”，而在于“设多少”。盲目设到 1G 虽然安全，但可能掩盖低效的批量逻辑（比如本该分批插入却硬拼成一条巨语句）；设太小又反复报错。建议按业务最大单次插入体积上浮 20%～30% 来定，而不是拍脑袋填个 1G。
