必须改mysql服务端max_allowed_packet，只在navicat执行set global是临时且不可靠的——重启后失效，也不影响新连接；需查show variables like 'config_file'确认配置路径，再用show variables和@@global/@@session区分真实生效值，且必须将max_allowed_packet=512m写在[mysqld]段下并重启服务。
必须改 MySQL 服务端的 max_allowed_packet，只在 Navicat 里执行 SET GLOBAL 是临时且不可靠的——重启后失效，也不影响新连接。
确认当前生效的 max_allowed_packet 值和配置文件位置
别凭印象改错文件。连上 MySQL（哪怕还能短暂连接），先查真实加载的配置路径：
SHOW VARIABLES LIKE 'config_file';
再查两个关键值：
SHOW VARIABLES LIKE 'max_allowed_packet';
注意区分 @@global.max_allowed_packet 和 @@session.max_allowed_packet。如果后者远小于前者，说明当前会话没继承全局设置——可能是 Navicat 连接时指定了低配参数，或用了权限受限的账号。
修改 MySQL 配置文件的硬性要求
max_allowed_packet 必须写在 [mysqld] 段下，否则 MySQL 启动时直接忽略，甚至报错退出。常见错误包括：
- 写在
[client]或[mysql]段下 → 无效 - 单位用小写
m或带B（如64mb、64MB）→ MySQL 启动失败 - 写成算式（如
64 * 1024 * 1024）→ 解析失败 - 路径搞错：Linux systemd 环境优先看
/etc/mysql/mysql.conf.d/mysqld.cnf；macOS Homebrew 安装是/opt/homebrew/etc/my.cnf；Windows 是C:\ProgramData\MySQL\MySQL Server X.X\my.ini（不是 Program Files 下那个）
✅ 正确写法示例：
[mysqld] max_allowed_packet = 512M
Navicat 16 侧能做的辅助动作
配置改完并重启 MySQL 后仍报错？说明 SQL 内容本身超限（比如含巨型 base64 字段、单条 INSERT 带几万行值、或备份文件含完整 BLOB 数据）。这时可尝试：
- 右键 Navicat 连接 → 编辑连接 → 高级 → 勾选「使用压缩协议」：不改变逻辑包大小，但能降低传输体积，对网络层有帮助
- 避免一次性还原整库大文件：拆成多个
.sql文件，按表或按批次导入 - 若文件来自 mysqldump，加
--skip-extended-insert参数重导：把多行 INSERT 拆成单行，减小单语句包体积（但会增大文件总大小）
注意：Navicat 16 的「导入向导」默认启用批处理，它可能把整个文件读入内存再发给服务端——所以光调大 max_allowed_packet 不够，源头上控制单次提交的数据量更稳妥。
最容易被忽略的一点：Docker 环境下，你改的 host 上的 my.cnf 如果没正确挂载进容器，等于白改。务必先 docker exec -it mysql_container cat /etc/mysql/my.cnf 确认内容已生效。
