确认是否为max_allowed_packet导致写入失败，需查错误日志中“Packets larger than max_allowed_packet are not allowed”或“Packet for query is too large (X > Y)”提示，并执行SELECT @@global.max_allowed_packet对比实际数据包大小，注意区分全局与会话级配置。
迁移后大字段写入失败，大概率是目标库 max_allowed_packet 小于源库或实际数据包大小，必须同步调大目标库该值，并确认客户端、服务端、会话三级配置全部生效。
怎么快速确认是不是 max_allowed_packet 导致写入失败
别猜，直接查错误日志和当前值：
- 错误信息里如果出现
Packets larger than max_allowed_packet are not allowed或Packet for query is too large (8808741 > 4194304)，括号里左边是实际包大小、右边是当前限制，基本坐实 - 登录目标库执行：
SELECT @@global.max_allowed_packet;，单位是字节；对比你写入的字段（比如一个 5MB JSON 字符串）是否超过它 - 注意：
SHOW VARIABLES LIKE 'max_allowed_packet'默认查 session 级，可能被 ORM 或连接池覆盖；必须用@@global看真实服务端限制 - 云数据库（如阿里云 RDS）常禁用
SET GLOBAL，此时查到的仍是默认值，得去控制台改参数组
为什么只改目标库配置文件还不够
改了 /etc/my.cnf 里的 [mysqld] 段，但写入仍失败，常见原因有三个：
- 配置段写错：写在
[client]或无段落处，MySQL 启动时完全忽略——必须严格放在[mysqld]下 - 单位写错：配置文件中允许
max_allowed_packet = 512M，但写成512MB、512m或带空格的512 M会导致 mysqld 启动失败 - 没重启服务：
mysqladmin reload或SIGHUP不重载此参数，必须systemctl restart mysql（或对应服务名） - 应用侧没同步：JDBC 连接串要加
maxAllowedPacket=536870912，PDO 要设PDO::MYSQL_ATTR_MAX_BUFFER_SIZE，否则客户端先截断
导入 SQL 文件或用 mysql 命令行写入时还报错怎么办
即使目标库服务端设对了，mysql 客户端默认仍用 16MB 上限，容易卡住：
- 命令行导入必须显式指定：
mysql --max-allowed-packet=512M -u root -p db_name < dump.sql - 如果用
source在交互式 mysql 中执行，需先运行：SET SESSION max_allowed_packet = 536870912;（注意是SESSION，不是GLOBAL） -
LOAD DATA INFILE是例外：它不走客户端缓冲，只依赖服务端max_allowed_packet和local_infile = ON，但云环境通常禁用local_infile，此时只能换mysqlimport或拆 INSERT - 别设超过 1G：MySQL 硬性上限是
1073741824（1GB），设成2G最终也只认 1G
迁移场景下最容易被忽略的兼容点
迁移不是单点调参，而是两端对齐：
- 目标库
max_allowed_packet必须 ≥ 源库，否则全量写入必然中断；官方建议至少设为 1GB（1024M） - 如果用了 binlog 复制（如 DTS、Canal），主库和从库的
max_allowed_packet也必须一致，否则 IO 线程报log event entry exceeded max_allowed_packet - 字符集、
sql_mode、explicit_defaults_for_timestamp等参数若不一致，虽不直接触发 packet 错误，但可能导致大字段内容被截断或转义异常，间接放大 packet 需求 - 某些 ORM（如 Django）会在连接建立时自动执行
SET SESSION max_allowed_packet = ...，若它设得太低，会覆盖你手动设的全局值——得查 ORM 文档关掉或调高
