直接修改max_allowed_packet可解决Navicat导入超限问题，需区分临时（SET GLOBAL）与永久（配置文件）生效方式，并注意其限制的是单条SQL、单个BLOB或LOAD DATA批次的网络包大小，而非整个SQL文件。
直接改 max_allowed_packet 就能过，但必须分清是临时生效还是永久生效，且不能只看文件总大小——关键在单条 insert 或单个 blob 字段是否超限。
查当前值：用 SHOW VARIABLES LIKE '%max_allowed_packet%' 确认真实限制
Navicat 导入失败时，别猜，先连上目标库执行这条命令。返回结果里重点关注 max_allowed_packet（主库接收上限）和 slave_max_allowed_packet（从库专用，不影响 Navicat 导入）。常见默认值是 4MB（4194304）或 16MB，远小于你那个 50MB 的单表 SQL 文件。
注意：max_allowed_packet 限制的是「一个网络包」的大小，不是整个 SQL 文件，也不是整个事务。它实际约束的是：
- 一条
INSERT语句中所有字段拼起来的原始字节长度（含转义、换行等） - 一个
LOAD DATA INFILE批次读取的行缓冲区 - BLOB/TEXT 字段单次传输的完整内容
所以 967MB 多表文件能过，而 50.1MB 单表文件报错——问题出在那张表里某几行带了超大日志文本或 base64 图片。
临时调高：用 SET GLOBAL max_allowed_packet = 1073741824 快速验证
在 Navicat 的命令行界面（F6）中执行：
SET GLOBAL max_allowed_packet = 1073741824;
这个值是 1GB，够大多数场景顶一阵子。执行后必须重新建立连接（关掉当前查询窗口再新开），否则新设置不生效。导入完建议立刻恢复原值，因为设太大可能引发：
- MySQL 进程内存占用飙升，尤其并发导入时
- 网络不稳定环境下丢包率上升（TCP 包过大易被中间设备截断）
- 某些云数据库（如阿里云 RDS）会忽略
SET GLOBAL，只认配置文件
如果执行后仍报错，说明服务端根本没接受这个 SET（比如权限不足），那就得走配置文件路线。
永久修改：编辑 my.ini 或 my.cnf 的 [mysqld] 段
找到 MySQL 配置文件（Windows 通常是 C:\ProgramData\MySQL\MySQL Server X.X\my.ini，Linux 是 /etc/my.cnf 或 /etc/mysql/my.cnf），在 [mysqld] 下加一行：
max_allowed_packet = 512M
不要写成 512*1024*1024，MySQL 只认带单位的写法（M 或 G）。改完必须重启 MySQL 服务，否则不生效。重点检查：
- 确认改的是服务端配置文件，不是客户端的
my.ini（Navicat 自带的不算） - 确认重启的是目标数据库实例，不是本地另一个 MySQL 实例
- 云数据库用户请查文档——RDS/Aurora 等通常提供控制台参数模板，不让你直接改文件
绕不开的坑：Navicat 自身缓存和分片逻辑也会影响
即使服务端 max_allowed_packet 调到 1G，Navicat 仍可能卡住，因为：
- 它默认把整个 SQL 文件读进内存再发给服务器，大文件容易触发客户端 OOM
- 遇到超长注释或无分号的巨型 INSERT，解析器可能误判包边界
- “运行 SQL 文件”功能不支持自动分片，而“数据传输”或“结构同步”模块反而更稳
真遇到死活过不去的情况，就拆文件：split -l 5000 big.sql part_（Linux）或用工具按 INSERT 分割。别信“只要服务器够大就一定能过”——Navicat 的行为边界，有时比 MySQL 本身还难预测。
