需同步修改客户端和服务端的max_allowed_packet配置并重启生效，且导入大文件时优先选用mysqlimport或切分SQL等更稳妥方式。
MySQL 导入报错 ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes 怎么办
这是 mysql 客户端或服务端拒绝接收超大 sql 包的典型错误，本质是单次传输的数据包超过了 max_allowed_packet 限制。不是文件太大不能导，而是某条语句（比如含长文本的 insert 或超长 load data 行）被拆成一个“包”，超了就直接断。
怎么改 max_allowed_packet 才真正生效
这个值在客户端、服务端、会话级三处都存在，只改一处常无效。必须同步确认：
- 服务端配置：修改
my.cnf（Linux）或my.ini（Windows）里的[mysqld]段，加max_allowed_packet = 512M（不建议直接写1G，部分旧版 MySQL 解析失败） - 客户端配置：在
[mysql]段也加同样配置，否则mysql命令行工具仍用默认 4MB - 重启
mysqld服务后，登录执行SHOW VARIABLES LIKE 'max_allowed_packet';，确认Value列显示的是你设的值（单位是字节，512M ≈ 536870912） - 如果用
source命令导入，它走的是客户端协议，所以客户端配置比服务端还关键
导入大文件时绕过 max_allowed_packet 的实操技巧
改参数治标，切分或换方式更稳，尤其面对不可控的生产环境：
- 用
mysqlimport替代source：它走的是LOAD DATA INFILE协议，不受客户端max_allowed_packet限制（但要求文件在数据库服务器本地，且secure_file_priv允许该路径） - 用
sed或split预处理 SQL 文件：例如split -l 5000 big.sql chunk_按行切分，再逐个source；注意别在事务中间切断 - 临时禁用自动提交 + 手动分段：在 SQL 文件开头加
SET autocommit=0;，每 1000 行左右加COMMIT;，避免单事务过大触发其他限制 - 避开
INSERT ... VALUES (...),(...),(...)这种多值写法：改成单行INSERT，虽然慢但包小；可用脚本把VALUES后的括号组逐行展开
为什么调到 1G 还报错？常见隐形坑
max_allowed_packet 不是越大越好，而且很多环节根本不读它：
- PHP 的
mysqli或PDO默认仍按自己的缓冲区走，需显式设置：$pdo->setAttribute(PDO::MYSQL_ATTR_MAX_BUFFER_SIZE, 536870912); - Docker 容器里改了
my.cnf，但没挂载进容器，或挂载路径错了（比如该挂/etc/mysql/my.cnf却挂到了/etc/my.cnf） - 云数据库（如阿里云 RDS、腾讯云 CDB）通常禁止修改
max_allowed_packet，只能提工单申请，或改用mysqlimport+ OSS 方式 - 某些备份工具（如
mysqldump）导出时用了--skip-extended-insert，反而让单行变长——这时调大参数没用，得换导出参数
真正卡住的往往不是配置本身，而是哪一层没对齐：客户端以为够了，服务端没加载，中间件又截了一刀。查清当前连接实际生效的值，比盲目调高更重要。
