报错“Got a packet bigger than 'max_allowed_packet' bytes”源于MySQL服务端与客户端双重限制未同步调整。需同时修改配置文件中[mysqld]和[mysql]段的max_allowed_packet值（如512M），并重启MySQL服务，导入时还需显式指定参数。
报错“Got a packet bigger than 'max_allowed_packet' bytes”不是网络问题，是MySQL服务端或客户端主动拒绝接收超长数据包。 单条 INSERT 语句含几万行值、含大 TEXT/BLOB 字段、或 mysqldump 导出的压缩 SQL 文件，都容易触发。只改配置文件里的 [mysqld] 段，90% 的情况仍会失败。
必须同时改服务端和客户端的 max_allowed_packet
MySQL 有两套独立的限制：服务端（mysqld）决定能否接收该包；客户端（如 mysql 命令行、SQLyog、Navicat）决定能否把包发出去。默认值常为：
- 服务端：
max_allowed_packet = 4M（部分旧版本仅 1M） - 客户端：
mysql工具默认仍是16M，但某些 Homebrew 或 Docker 镜像版本根本不读[client]段
所以必须双改：
- 在
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf的[mysqld]段加：max_allowed_packet = 512M - 在同一文件的
[mysql]段也加：max_allowed_packet = 512M（注意不是[client]） - 改完必须重启服务：
sudo systemctl restart mysql（Debian/Ubuntu）或sudo systemctl restart mysqld（RHEL/CentOS）
用 mysql 命令导入时，还得显式传参
即使配置文件写对了，mysql -u root -p db_name 这种管道导入仍可能失败——因为客户端进程启动时没加载新配置，或加载了但被命令行参数覆盖。
- 安全做法是显式指定：
mysql --max-allowed-packet=512M -u root -p db_name - 如果用
source在交互式 mysql 中执行，得先运行：SET SESSION max_allowed_packet = 536870912;（注意是SESSION，不是GLOBAL） - 别信“改了 my.cnf 就一劳永逸”，macOS Homebrew 安装的
mysql默认不读系统级my.cnf，只读~/.my.cnf
调大参数只是前提，SQL 脚本本身得适配
设成 2G 还报错？常见原因不是参数不够，而是脚本结构不合理：
- 单条
INSERT INTO ... VALUES (),(),()...含 50 万行 → MySQL 解析器内存爆掉，某些 5.7 版本隐式限制约 100MB/语句 - 用
sed -i 's/),(/),\n(/g'强行换行拆分前，务必先cp big.sql big.sql.bak，否则损坏不可逆 - 更稳妥方式：用
split-sql工具或 Python 脚本按每 1–2 万行切分，并在每批后加COMMIT; - 终极提速方案：
LOAD DATA INFILE或mysqlimport，它们绕过 SQL 解析，只受服务端max_allowed_packet和local_infile开关控制
真正容易被忽略的是：调大 max_allowed_packet 后，如果导入依然卡住或慢得异常，大概率是 innodb_log_file_size 太小导致频繁刷盘，或者没关 unique_checks 和 foreign_key_checks。这些优化点比单纯调包大小影响更大。
