必须修改服务器端配置文件中的max_allowed_packet并重启服务，仅在navicat中执行set global是临时且易失效的；该错误源于mysql服务端主动拒绝超限数据包，并非网络或客户端问题。
必须改服务器端的 max_allowed_packet，只在 navicat 里执行 set global 是临时且易失效的。 这个错误本质是 mysql 拒绝接收超过限制的单次 sql 请求包，不是 navicat 的 bug，也不是网络问题——它只是把底层通信限制暴露了出来。
确认当前值和实际生效位置
别猜配置文件在哪，也别信“我刚改过了”。先连上 MySQL（哪怕报错前还能连），执行：
SHOW VARIABLES LIKE 'config_file';
返回路径才是真实加载的配置文件。再查当前值：
SHOW VARIABLES LIKE 'max_allowed_packet';
注意看两个值：@@global.max_allowed_packet 和 @@session.max_allowed_packet。如果后者明显小于前者，说明你当前会话没继承全局设置——可能连接时指定了低配参数，或用了不同用户权限。
- Linux systemd 环境下，优先检查
/etc/mysql/mysql.conf.d/mysqld.cnf，不是/etc/my.cnf - macOS Homebrew 安装，路径通常是
/opt/homebrew/etc/my.cnf（Apple Silicon） - Windows 注意是
C:\ProgramData\MySQL\MySQL Server X.X\my.ini，不是Program Files下那个 - Docker 容器内运行？先
docker exec -it mysql_container cat /etc/mysql/my.cnf确认挂载点
修改配置文件的硬性要求
max_allowed_packet 必须写在 [mysqld] 段下，单位后缀必须大写 M，不能用 MB 或小写 m，也不能写算式。
- ✅ 正确：
max_allowed_packet = 64M或max_allowed_packet = 67108864 - ❌ 错误：
max_allowed_packet = 64MB、max_allowed_packet = 64m、max_allowed_packet = 64 * 1024 * 1024 - ⚠️ 即使写对了，若放在
[client]段或无段落头的位置，MySQL 启动时直接忽略，甚至启动失败
改完不重启服务 = 白改。systemd 环境用 sudo systemctl restart mysqld；Homebrew 用 brew services restart mysql；Windows 用服务管理器或 net stop MySQL80 && net start MySQL80。
Navicat 侧可做的辅助缓解
配置文件改完重启后仍报错？大概率是 Navicat 提交的 SQL 本身超限，比如含巨型 base64 字段或单条 INSERT INTO ... VALUES (),(),()... 超过 64MB。这时光调大 max_allowed_packet 不够，还得拆包：
- 右键连接 → 编辑连接 → 高级 → 勾选「使用压缩协议」（降低传输体积，但不改变逻辑包大小）
- 导入 SQL 文件时，用 Navicat 16+ 的「导入向导」→「高级」→ 开启「分批执行」，设
batch size = 1000 - 生成 dump 时用
mysqldump --skip-extended-insert --net-buffer-length=64k，确保每行一个INSERT - 启用 Navicat「工具 → 选项 → 调试 → 记录查询日志」，定位具体哪条语句触发了
(11831623 > 4194304)这类提示
容易被忽略的多实例陷阱
本地开发常同时跑 Docker 容器、Homebrew MySQL、云数据库多个实例。你改的是 /etc/my.cnf，但 Navicat 连的是 localhost:3307（Docker 映射端口），实际连的根本不是那个配置文件控制的服务。务必用 SHOW VARIABLES LIKE 'config_file' 确认目标实例，再动手改。临时 SET GLOBAL 更危险：它只影响当前会话所在实例，且服务重启即丢，还可能因权限不足失败。
