最可靠方式是修改c:\programdata\mysql\mysql server 5.7\my.ini中[mysqld]节下的max_allowed_packet值（如64m），以管理员权限保存后重启mysql服务，并用show global variables like 'max_allowed_packet';验证。
直接改 my.ini 里的 max_allowed_packet 并重启服务，是最可靠的方式；临时用 SET GLOBAL 设置基本无效，且重启后丢失。
怎么找到并编辑正确的 my.ini 文件
MySQL 5.7 在 Windows 下默认不把 my.ini 放在安装目录里，而是在隐藏的 C:\ProgramData\MySQL\MySQL Server 5.7\my.ini。这个路径必须确认，不能只看 MySQL 安装目录下的 bin 或 support-files 文件夹。
- 打开命令行，运行
mysql --help | findstr "Default options"，它会输出类似Default options are read from the following files : C:\ProgramData\MySQL\MySQL Server 5.7\my.ini的提示，这就是真实加载的配置文件 - 用管理员权限打开记事本或 Notepad++ 编辑该文件——没管理员权限会导致保存失败，看似改了实则没写入
- 别搜“末尾添加”，要搜
max_allowed_packet全文，如果已有就直接改值；没有就加到[mysqld]节下（不是[client]或[mysql]）
为什么写在 [mysqld] 下才生效
max_allowed_packet 是服务端参数，只对 mysqld 进程起作用。写在 [client] 或 [mysql] 下，只会改变客户端连接时的默认行为，不影响服务器接收包的能力。
- 常见错误：把
max_allowed_packet = 64M放在文件最后、或[mysql]段下，SHOW VARIABLES仍显示 4194304（即 4M） - 正确位置必须是
[mysqld]节内，且该节不能拼错（比如写成[mysqld1]或漏掉d） - 单位支持
K、M、G，推荐用64M或128M；不要写67108864这类纯数字，易出错也不直观
修改后不生效？重点检查这三件事
很多“改了没用”其实是重启流程不对或状态没验证准。
- 任务管理器里右键“MySQL57”服务 → “重新启动”，不是“启动”或“停止+启动”——后者可能残留旧进程
- 重启后进 MySQL 命令行，执行
SHOW GLOBAL VARIABLES LIKE 'max_allowed_packet';，注意一定要加GLOBAL，否则可能看到会话级旧值 - 如果值还是 4194304，立刻查 Windows 事件查看器 → Windows 日志 → 应用程序，筛选 MySQL 服务启动记录，看是否有“unknown variable”或配置解析失败警告
大对象场景下还要注意 slave_max_allowed_packet
如果你开了主从复制，尤其是用 row-based replication 插入含大 BLOB 或 TEXT 的数据，光调 max_allowed_packet 不够。
- 从库（replica）需要能接收主库发来的完整事件包，所以它的
slave_max_allowed_packet默认是 1G，一般不用动 - 但真正卡住的是
slave_pending_jobs_size_max，它控制从库内存中暂存事件的上限，默认 128M；若主库max_allowed_packet设为 256M，而这个值没同步调高，从库 I/O 线程会静默中断 - 建议设为 ≥ 主库
max_allowed_packet值，例如主库设128M，从库就配slave_pending_jobs_size_max = 134217728（单位字节）
真正麻烦的不是改哪个数字，而是确认改的是哪个文件、哪个段、被哪个进程加载；哪怕只多一个空格或少一个换行，Windows 下的 MySQL 5.7 也可能静默忽略整段配置。
