主从库 max_allowed_packet 值必须一致且均配置在 [mysqld] 段并重启生效；若不一致，从库同步会因 binlog event 超限中断，错误提示为 “log event entry exceeded max_allowed_packet”，需通过 SELECT @@global.max_allowed_packet; 确认真实服务端值，并同步调整客户端、备份及导入工具参数。
max_allowed_packet 值必须一致，且都设在 [mysqld] 段、重启生效；只调大主库或只改客户端配置，从库照样同步失败。
查错误日志确认是不是这个参数惹的祸
从库复制中断时，SHOW SLAVE STATUS\G 里如果看到 Last_IO_Error: log event entry exceeded max_allowed_packet，基本就是它。注意这不是网络超时或权限问题，是协议层直接拒收——主库 binlog event 体积超过了从库能接收的上限。
别依赖 SHOW VARIABLES LIKE 'max_allowed_packet'，它默认返回会话值（可能被连接池覆盖），要执行：SELECT @@global.max_allowed_packet; 看真实服务端限制。对比你最大事务生成的 binlog event 大小（比如一个含 4MB JSON 的 INSERT），就能坐实。
主从都得改，且必须改对位置和单位
max_allowed_packet 是服务端参数，只认 [mysqld] 段配置。写在 [client] 或无段落处，MySQL 启动时直接忽略。
常见坑点：
• 配置写成 max_allowed_packet = 512MB 或 512m —— 必须用 512M（大写 M），带空格或单位错会导致 mysqld 启动失败
• 改完没重启：mysqladmin reload 或 SIGHUP 不重载该参数，必须 systemctl restart mysql
• 云数据库（如阿里云 RDS）禁用 SET GLOBAL，得去控制台修改参数模板，并重启节点（不是“重载”）
应用和工具链也得同步适配
即使主从服务端都调对了，以下环节仍可能卡住：
• JDBC 连接串漏加 maxAllowedPacket=536870912，客户端先截断再发给服务端
• mysqldump 备份时没加 --max-allowed-packet=4G，备份文件本身生成失败
• 用 mysql 命令行导入 SQL 文件，必须显式指定：mysql --max-allowed-packet=512M -u root -p db ，否则用默认 16MB 上限<br>• <code>LOAD DATA INFILE 同步失败？先确认从库 local_infile 是否为 ON（SELECT @@local_infile;），云环境通常禁用，得换 mysqlimport 或拆 INSERT
别盲目设到 2G 以上
max_allowed_packet = 2G 并不等于你能安全处理 2GB 的数据包。MySQL 内部协议开销、内存分配策略、以及某些版本对 >1G 值的兼容性都不稳定。实测中设到 1G（即 1073741824）已覆盖绝大多数场景，再往上容易触发隐性内存不足或解析异常。真正的大字段写入，优先考虑业务层拆分或改用 BLOB + 分片逻辑，而不是硬扛参数上限。
