最稳妥方案是修改XAMPP的my.ini文件中[mysqld]段的max_allowed_packet值（如设为64M），并重启MySQL服务；需同步在[client]段设置相同值，且调整PHP相关上传限制，否则大SQL导入仍会失败。
直接改 my.ini 并重启 MySQL 服务，是最稳妥的方案。临时用 SET GLOBAL 很容易失效，尤其在 XAMPP 这种本地开发环境里，连接池、phpMyAdmin、命令行工具各自读取的会话值可能不一致。
怎么找到并修改 XAMPP 的 my.ini 文件
XAMPP 的 MySQL 配置文件不是系统级的 my.cnf，而是安装目录下的 my.ini。Windows 下典型路径是：D:\xampp\mysql\bin\my.ini 或 D:\xampp\mysql\my.ini（具体看你的安装路径）。别去 C:\Windows\ 下找，那里的是系统默认模板，XAMPP 不读它。
打开该文件，在 [mysqld] 段落末尾添加或修改这一行：
max_allowed_packet = 64M
注意几点：
- 必须写在
[mysqld]下，写在[client]或文件开头无效 - 支持后缀
M（兆字节），不用换算成字节；写67108864也行，但易错 - 别设成
1G—— XAMPP 默认内存有限，高并发时可能触发 OOM - 改完保存，然后通过 XAMPP Control Panel 重启 MySQL（不是只点“Start”，要先 Stop 再 Start）
为什么 SET GLOBAL max_allowed_packet 在 XAMPP 里常失效
执行 SET GLOBAL max_allowed_packet = 67108864; 看似快，但在 XAMPP 场景下问题很多：
- phpMyAdmin 页面刷新后仍用旧会话，不会自动继承新全局值
- Navicat、SQLyog 等客户端一旦连上，就锁定当时的会话值，重连才生效
- XAMPP 自带的命令行工具（
mysql.exe）默认从[client]段读配置，不认GLOBAL设置 - 某些版本的 MySQL（尤其是 XAMPP 捆绑的老版 5.7.x）对
SET GLOBAL后的内存分配有延迟，实际缓冲区没立刻扩大
查当前生效值，得分别看：
全局值：SELECT @@global.max_allowed_packet;
当前会话值：SELECT @@session.max_allowed_packet;
如果两者不一致，说明客户端没重连，或者压根没读到新配置。
导入大 SQL 文件失败？还要同步调客户端侧
即使 MySQL 服务端设到了 64M，用 mysql 命令行导入 50MB 的 SQL 文件仍可能报 Got a packet bigger than 'max_allowed_packet' bytes —— 因为客户端工具自己也有限制。
解决方法有两个：
- 在
my.ini的[client]段加一行：max_allowed_packet = 64M（和 [mysqld] 下保持一致） - 导入时显式指定参数：
mysql -u root -p --max-allowed-packet=64M database_name < dump.sql
如果你用 phpMyAdmin 导入，还得额外调 PHP 层限制：upload_max_filesize、post_max_size、memory_limit 都得 ≥ 64M，否则文件根本传不到 MySQL。
设多大才算合理
别盲目堆高。XAMPP 是本地开发环境，不是生产服务器：
- 默认 4M（4194304）够大多数小项目用
- 处理含 base64 图片字段、长 JSON、单条超 10MB 的导出数据，64M 是较安全的上限
- 设到 256M 或 1G 容易导致 XAMPP 启动失败，或 MySQL 进程被 Windows 系统终止（OOM killer）
- 每次改完，务必用
show variables like 'max_allowed_packet';确认值已更新，且重启后依然存在
最容易被忽略的是：改了 my.ini 却忘了重启 MySQL 服务，或者改了 [mysqld] 段却漏掉 [client] 段 —— 这两个不一致，导入和查询就会表现不一致。
