需同步修改客户端和服务端的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，反而让单行变长——这时调大参数没用，得换导出参数

真正卡住的往往不是配置本身，而是哪一层没对齐：客户端以为够了，服务端没加载，中间件又截了一刀。查清当前连接实际生效的值，比盲目调高更重要。