必须同时调大服务端和客户端的max_allowed_packet，只改一边基本无效；服务端需在my.cnf的[mysqld]段设值并重启，客户端导入时须显式指定--max-allowed-packet参数，且位置和单位须严格正确。
必须同时调大服务端和客户端的 max_allowed_packet，只改一边基本无效。错误码 ERROR 1153 或 ERROR 2020 看似是服务端限制，但大概率卡在客户端发包阶段——比如 mysql 命令行工具自己就默认只收 4MB 或 16MB 的包，根本没机会把完整 SQL 送到服务器。
查清当前实际生效值在哪边
服务端和客户端的 max_allowed_packet 是独立变量，不能只看配置文件或只执行 SET GLOBAL 就以为万事大吉：
- 查服务端当前值：
SHOW VARIABLES LIKE 'max_allowed_packet'; - 查客户端当前会话值（在
mysqlshell 里运行）：SHOW SESSION VARIABLES LIKE 'max_allowed_packet'; - 图形化工具（如 DBeaver、Navicat）不读
my.cnf，得在连接参数里加maxAllowedPacket=268435456，或连上后手动执行SET SESSION max_allowed_packet = 268435456;
永久修改服务端配置（mysqld）
只改临时变量或客户端参数，重启服务后就失效。必须写进配置文件并重启：
- 宝塔用户路径通常是
/www/server/mysql/my.cnf；通用 Linux 路径是/etc/my.cnf或/etc/mysql/my.cnf - 在
[mysqld]段下添加：max_allowed_packet = 256M（单位必须大写M，不能写MB或小写m） - 改完必须重启服务：
service mysqld restart或systemctl restart mysqld - 注意：设太大（如 >512M）可能在内存紧张的线上机器引发 OOM，256M 是较稳妥的上限
命令行导入时客户端参数必须放对位置
用 mysql db_name 方式导入时，<code>--max_allowed_packet 参数不是可有可无的开关，它必须出现在命令最前面，且单位格式要严格：
- ✅ 正确：
mysql --max_allowed_packet=256M -u root -p db_name - ❌ 错误：
mysql -u root -p --max_allowed_packet=256MB db_name （位置错 + 单位错） - 如果用
source在交互式 shell 导入，得先执行：SET SESSION max_allowed_packet = 268435456; - 别忽略
net_buffer_length：它控制分包缓冲，默认 16KB，遇到超长INSERT ... VALUES (...), (...), ...容易拆包失败，建议同步设为1048576（1MB）
导出也得同步配参，否则 dump 文件本身就不合法
mysqldump 是客户端，它从服务端拉数据时同样受 max_allowed_packet 限制。如果表里有大 BLOB 或长文本，导出会直接报 ERROR 2020：
- 导出命令必须加：
mysqldump --max-allowed-packet=256M -u root -p db_name > dump.sql - 若仍失败，可配合
--skip-extended-insert把多值INSERT拆成单行，降低单包体积 - 预估该设多大？用
awk '{print length}' dump.sql | sort -nr | head -1查最长行字节数，再加 20% 余量——不是越大越好，过大会掩盖脏数据（比如调试残留的 200MB 字符串）
最容易被忽略的是：图形化工具、Docker 容器、云数据库（如阿里云 RDS）各自管理自己的客户端参数，它们不继承宿主机的 my.cnf。哪怕服务端已调到 512M，Navicat 连接时没显式设，照样报 1153。
