navicat或命令行导入时max_allowed_packet过小会导致单条超长insert被拒，报error 2006或1153；该参数在服务端和客户端各自独立生效，需同步调整：navicat可通过变量页临时设为256m，命令行须显式传参--max-allowed-packet=512m，云数据库通常仅支持配置文件修改并重启。
max_allowed_packet 过小导致单条语句被拒
这是 Navicat 或命令行导入时最常撞上的点：一个 INSERT INTO ... VALUES (),(),()... 包含上千行，体积轻松突破默认 4MB 限制，MySQL 直接丢连接，报错 ERROR 2006 或 ERROR 1153。
-
max_allowed_packet是服务端和客户端**各自独立生效**的参数，只调服务端配置，客户端（如mysql命令）仍按默认值收包 - Navicat 里临时改：工具 → 服务器监控 → 变量页 → 找到
max_allowed_packet→ 改为268435456（256MB）→ 点“刷新” - 命令行导入必须显式传参：
mysql --max-allowed-packet=512M -u root -p db_name - 云数据库（如阿里云 RDS）通常禁用
SET GLOBAL，只能靠配置文件 + 重启
wait_timeout / interactive_timeout 超时断连
导入耗时超过默认 28800 秒（8 小时）？不，很多大 SQL 实际执行就卡在 30 分钟内——因为 wait_timeout 默认是 28800 秒没错，但部分 MySQL 8.0+ 版本在非交互式导入（如管道重定向）下实际走的是 wait_timeout，而非 interactive_timeout。
- 两个 timeout 必须**同时设**，且值一致，否则行为不可预测
- 临时生效需退出当前会话再重连：
SET GLOBAL wait_timeout = 86400;→ 关闭终端 → 新开终端再导入 - 验证当前会话值用：
SELECT @@session.wait_timeout, @@session.interactive_timeout;，别只看SHOW VARIABLES - my.cnf 中写法要带单位后缀：
max_allowed_packet = 512M，不能写536870912或512*1024*1024
SQL 文件本身带 BOM 或语法破坏
UTF-8 BOM（EF BB BF）出现在文件开头，会让 MySQL 把第一行解析成乱码语句，后续所有 CREATE、INSERT 全部错位，间接触发超时或包解析失败——现象是“建表成功，插入全挂”，日志里却找不到明显错误。
- 用
file -i dump.sql（Linux）或 VS Code 编码检测确认是否含 BOM - 去除 BOM：Linux 下用
sed -i '1s/^\xEF\xBB\xBF//' dump.sql；Windows 用 Notepad++ → 编码 → 转为 UTF-8 无 BOM - 别用
split -l 10000硬切 SQL 文件——INSERT语句跨行、事务块被截断、注释中断都会直接让导入失败 - 真正安全的分片方式：用
mysqldump --skip-extended-insert导出，或用pt-online-schema-change类工具做流式加载
客户端与服务端参数未对齐
你改了服务端 max_allowed_packet = 512M，但 Navicat 或 mysql 客户端没同步，照样报错。这不是服务端问题，是通信协议层面的“双方说不同语言”。
- 检查客户端实际生效值：
mysql --help | grep "max-allowed-packet" - Navicat 没提供客户端参数配置入口，所以必须靠 GUI 变量页或服务端全局设置兜底
- PHP/Python 应用里要显式设置连接参数，例如 PyMySQL 的
max_allowed_packet参数、PDO 的ATTR_TIMEOUT - 即使所有参数都调高，2GB+ SQL 文件仍可能因磁盘 I/O 或内存不足失败——此时分段导入比硬扛更可靠，也更容易定位哪一段出错
show global status like 'uptime'; 排除服务宕机；再看报错前最后一句 SQL 是 INSERT 还是空闲等待，就能快速锁定是包大小还是超时问题。BOM 和分片方式这种细节，往往被跳过，却最容易浪费半天时间。
