报“Packet for query is too large”错误，说明单个网络包超限，需双向同步调大max_allowed_packet：服务端在[mysqld]段设max_allowed_packet=512M并重启，客户端（JDBC、mysqldump等）也须显式配置对应值，单位严格为大写M，且必须验证实际生效。
报 Packet for query is too large 错误，说明你发给 MySQL 的单个网络包（比如一条含大 JSON 的 INSERT、一个超长 SELECT 结果、或 mysqldump 导出的一整条语句）超过了服务端或客户端当前允许的最大尺寸。这不是 SQL 写错了，而是协议层直接切断连接——必须双向调对参数，且单位、位置、重启缺一不可。
怎么确认真是 max_allowed_packet 问题
错误信息里明确带括号数字对比，就是它：
-
Packet for query is too large (8808741 > 4194304)：左边是实际包大小（字节），右边是当前限制值（4194304 = 4MB） -
Got packet bigger than 'max_allowed_packet' bytes或Packets larger than max_allowed_packet are not allowed - 执行
SHOW VARIABLES LIKE 'max_allowed_packet';看到的值远小于你操作的数据体积（比如插入 5MB JSON 却只设了 4MB） - 注意：
@@session.max_allowed_packet可能被连接池或 ORM 覆盖，优先查@@global.max_allowed_packet
服务端配置必须写对位置、单位、并重启
改配置文件不是“加一行就完事”。MySQL 只在启动时读取 [mysqld] 段里的值，且单位校验极严：
- 先用
SHOW VARIABLES LIKE 'config_file';查真实生效的配置文件路径（常见：/etc/my.cnf、/etc/mysql/mysql.conf.d/mysqld.cnf） - 只允许写在
[mysqld]段下，例如：max_allowed_packet = 512M；写在[client]或无段落处完全无效 - 单位必须是大写
K/M/G，512MB、512m、512 M全部导致 MySQL 启动失败 - 改完不重启 = 白改：
sudo systemctl restart mysql（或mysqld，看服务名）；mysqladmin reload不起作用 - 重启后执行
SELECT @@global.max_allowed_packet;验证是否真生效（返回值单位是字节，512M 应显示536870912）
客户端侧常被忽略的三类限制
即使服务端设成 1G，客户端没配对，照样报错：
-
JDBC 连接串：必须显式加参数，如
?maxAllowedPacket=536870912（单位字节），max_allowed_packet=512M在 URL 里无效 -
mysqldump 命令：必须用
--max-allowed-packet=512M，且该参数必须放在数据库名之前；不加则默认仍用 4MB - Navicat / DBeaver 等 GUI 工具：它们有自己的发送缓冲区设置（如 Navicat 的「SQL 脚本执行缓冲区」），光改 MySQL 配置没用
为什么设了 1G 还失败？关键盲区
最常踩的坑不是不会改，而是改错了对象或层级：
- 你以为改的是主库，程序实际连的是从库或中间件（Proxy、读写分离路由），而从库的
my.cnf没同步改 - 云数据库（如阿里云 RDS、腾讯云 CDB）禁用
SET GLOBAL，控制台参数组修改后需手动应用并重启实例 - Docker 环境下，
my.cnf必须通过 volume 正确挂载进容器内/etc/mysql/my.cnf，改宿主机文件毫无意义 - 某些 ORM（如 MyBatis）或连接池（如 HikariCP）会主动截断超长语句，日志里报的错可能来自驱动层而非 MySQL 服务端
真正生效的调优，从来不是单点修改，而是确认服务端加载哪个文件、单位是否大写、客户端是否同步协商、以及你连的到底是哪台 MySQL 实例——漏掉任意一环，错误照旧。
