必须同时调大源库和目标库的max_allowed_packet且值一致（至少目标≥源），因为源库决定能否生成大包（如480M binlog event），目标库决定能否接收解析该包；若仅调大目标库，源库仍受限于旧值无法生成大包，迁移工具将因包大小不匹配而失败。
必须同时调大源库和目标库的 max_allowed_packet，且值要一致（至少目标 ≥ 源），否则全量或增量迁移都会失败。
为什么只改目标库还不够
迁移工具（如 DTS、mysqldump + mysql、自研同步程序）本质上复用 MySQL 复制协议逻辑：源库生成的 binlog event 或导出数据包，必须被目标库完整接收并解析。如果源库 max_allowed_packet 是 512M，它就可能生成一个 480M 的大事务 event；但目标库若仍是默认 4MB，IO 线程或导入客户端直接拒收，报错类似 Last_IO_Error: log event entry exceeded max_allowed_packet 或 Packets larger than max_allowed_packet are not allowed。
- 源库值决定“能不能产生大包”，目标库值决定“能不能收下这个包”——两者缺一不可
- 云数据库（如阿里云 RDS、腾讯云 TDSQL）通常禁用
SET GLOBAL，必须走控制台参数模板修改，并重启实例 - 即使你改了目标库，若迁移工具本身（如
mysqldump）没同步调大客户端参数，仍会在本地截断
怎么确认当前生效值
别猜配置文件有没有写对，直接连上去查：
- 查源库全局值：
SELECT @@global.max_allowed_packet;（单位字节，4194304 = 4MB） - 查目标库全局值：
SELECT @@global.max_allowed_packet; - 如果用
mysql命令导入，再查客户端实际值：mysql --help | grep "max-allowed-packet" - 注意：
@@session.max_allowed_packet只反映当前连接协商结果，不能代表服务端底线
配置必须写在 [mysqld] 段并重启
max_allowed_packet 是服务端参数，只在 [mysqld] 段生效。写在 [client] 或 [mysql] 段对迁移无用——因为复制线程是 mysqld 自身进程，不是外部客户端。
- 正确写法（/etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）：
[mysqld] max_allowed_packet = 512M
- 错误写法：
[client] max_allowed_packet = 512M（迁移时完全无效） - 改完必须执行
systemctl restart mysql（或对应服务名），mysqladmin reload不触发重载 - 设成
2G可能失败：MySQL 启动时会尝试分配连续内存，物理内存不足或内核限制会导致启动失败，建议上限设为1G并确保net_buffer_length足够（通常默认 1MB 即可）
客户端工具也要显式指定
即使源/目标库都设对了，mysqldump 导出或 mysql 导入时仍可能卡住——因为这些命令行工具自带默认包大小限制（mysqldump 默认约 24MB，mysql 默认 16MB）。
- 导出时加参数：
mysqldump --max-allowed-packet=512M -u user db_name > dump.sql - 导入时加参数：
mysql --max-allowed-packet=512M -u user db_name - 若用
source在交互式 mysql 中执行，先运行：SET SESSION max_allowed_packet = 536870912;（注意是SESSION，且需在source前执行） - LOAD DATA INFILE 场景特殊：它不走客户端缓冲，只依赖服务端
max_allowed_packet和local_infile = ON，但云环境通常禁用local_infile，此时应改用mysqlimport或分批INSERT
最容易被忽略的是：迁移任务里源库和目标库的 max_allowed_packet 值不同步，且配置写错了段落——这种问题不会报明确错误，而是静默失败或间歇性中断，排查时得两边都登录查 @@global.max_allowed_packet，而不是只看配置文件有没有改。
