主从max_allowed_packet值必须完全一致且均配置在[mysqld]段并重启生效；若不一致，从库last_io_error报“log event entry exceeded max_allowed_packet”，属协议层拒收，非网络或权限问题，需用select @@global.max_allowed_packet确认真实服务端值并同步调整客户端及工具参数。
主从 max_allowed_packet 值必须完全一致，且都设在 [mysqld] 段
从库 Last_IO_Error 出现 log event entry exceeded max_allowed_packet，不是网络或权限问题，是协议层直接拒收——主库生成的 binlog event 体积超过了从库能接收的上限。只调大主库、或只改客户端配置，从库照样同步失败。
必须同时确认并统一主从两端的 @@global.max_allowed_packet 值（单位字节），不能只看 SHOW VARIABLES LIKE 'max_allowed_packet'，它返回的是会话值，可能被连接池覆盖。
- 主库过小：大事务根本进不了 binlog，从库再大也解析不了空事件
- 从库过小：IO 线程直接中断，
Slave_IO_Running: No - 配置必须写在
[mysqld]段，写在[client]或无段落处，MySQL 启动时忽略 - 单位必须用大写
M，如512M；写成512MB、512m或带空格的512 M，会导致mysqld启动失败
改完配置不重启 = 白改
max_allowed_packet 是静态参数，SET GLOBAL 在某些版本下看似成功，但复制 IO 线程不认，必须改配置文件后完整重启服务。
- Linux 执行：
systemctl restart mysqld（注意不是reload或mysqladmin flush-logs） - 云数据库（如阿里云 RDS）禁用
SET GLOBAL，必须通过控制台修改参数模板，并重启节点（不是“重载”） - 改完立即验证：
SELECT @@global.max_allowed_packet;，确保主从数值完全相同
mysqldump / mysql 导入时也得同步设 --max-allowed-packet
即使主从服务端都设对了，mysqldump 备份或 mysql 命令行导入仍可能卡住——因为这些是独立客户端，不继承服务端配置，也不读 [client] 段（mysqldump 尤其如此）。
-
mysqldump必须显式加参数：mysqldump --max-allowed-packet=512M -u root -p db_name > dump.sql，且--max-allowed-packet必须放在数据库名之前 -
mysql导入时同样要指定：mysql --max-allowed-packet=512M -u root -p db_name - 交互式
mysql中用source，得先执行：SET SESSION max_allowed_packet = 536870912;（注意是SESSION，GLOBAL对当前连接无效） - JDBC 连接串漏加
maxAllowedPacket=536870912，客户端会在发给服务端前就截断
别盲目设到 2G 以上
max_allowed_packet = 2G 并不等于你能安全处理 2GB 的数据包。MySQL 内部协议开销、内存分配策略、以及部分版本（如 5.7.20 之前）对 >1G 值的兼容性都不稳定。
- 实测中设为
1073741824（即 1G）已覆盖绝大多数场景 - 设更大反而容易触发隐性内存不足或解析异常
- 真正容易被忽略的是：报错显示 packet 超限，但根源可能是源数据里一个未转义换行符，导致 MySQL 把整行当单个 packet 解析——这时该检查 CSV/SQL 文件的行宽，而不是继续加码
