看到#1153错误即可锁定为max_allowed_packet超限，需同步调大MySQL服务端、PHP上传限制（upload_max_filesize/post_max_size）及phpMyAdmin运行时配置，并验证SHOW VARIABLES结果是否生效。
phpMyAdmin 5.0 导出报错 #1153 怎么确认是 max_allowed_packet 引起的
看到 #1153 - got a packet bigger than 'max_allowed_packet' bytes 就基本可以锁定问题——不是权限、不是表损坏，就是单条 sql（通常是某条含大 text/blob 的 insert）打包后超长了。phpmyadmin 5.0 自身不显示原始 mysqldump 日志，所以得靠排除法：如果命令行 mysqldump 能导出，而 phpmyadmin 导出为空或中断，大概率是它卡在上传/解析阶段而非 mysql 执行阶段。
必须同步改 MySQL 服务端和 PHP 层三处配置
只改 MySQL 的 max_allowed_packet 没用，因为 phpMyAdmin 是 PHP 程序，整个流程要过三道关：
- MySQL 服务端：
/www/server/mysql/etc/my.cnf的[mysqld]段加max_allowed_packet = 512M，然后执行service mysqld restart - PHP 上传限制：
/www/server/php/{版本号}/etc/php.ini中调大upload_max_filesize = 2048M、post_max_size = 2048M、max_execution_time = 3600，再执行service php-fpm-{版本号} restart - phpMyAdmin 运行时限制：编辑
/www/server/phpmyadmin/config.inc.php，末尾加三行：ini_set('upload_max_filesize', '2048M');、ini_set('post_max_size', '2048M');、ini_set('max_execution_time', '3600');
注意：max_allowed_packet 在 MySQL 配置里单位必须是 M（大写），不能写 m 或 MB；PHP 侧没有同名参数，靠那三个 ini_set 补位。
导出时仍失败？检查 mysqldump 是否被静默调用
phpMyAdmin 5.0 默认用内置逻辑生成 SQL，但某些场景（如选“自定义”导出、勾选“添加 DROP TABLE”）会后台调用系统 mysqldump。如果宝塔没配好 mysqldump 路径或权限，它可能 fallback 到低效的 SELECT 拼接方式，反而更容易触发包限制。
- 确认
mysqldump可用：在宝塔终端执行which mysqldump，应返回类似/www/server/mysql/bin/mysqldump - 检查 phpMyAdmin 是否启用外部工具：打开
/www/server/phpmyadmin/config.inc.php，找$cfg['ExecTimeLimit']和$cfg['SaveDir']，确保没禁用导出功能 - 临时绕过：导出时取消勾选“扩展插入”（即禁用
--extended-insert），让每行生成独立 INSERT，单包压力骤降——代价是文件变大、导入慢，但能快速验证是不是包大小问题
改完怎么验证是否真正生效
别信重启日志，直接查运行值：
立即学习“PHP免费学习笔记（深入）”；
- 进 phpMyAdmin → 「SQL」页，执行
SHOW VARIABLES LIKE 'max_allowed_packet';，看返回值是不是你设的（比如536870912对应 512M） - 同时执行
SELECT @@global.max_allowed_packet, @@session.max_allowed_packet;，确认两者一致且非默认 4194304（4M） - 在宝塔终端执行
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';"，排除 phpMyAdmin 缓存干扰
最容易忽略的一点：phpMyAdmin 5.0 的导出按钮点击后，请求走的是 PHP-FPM 进程，不是 MySQL 连接池——所以哪怕 MySQL 服务端值对了，只要 PHP 的 post_max_size 还卡在 8M，文件根本传不到后端解析环节，错误日志里也不会提 max_allowed_packet，只会静默失败或返回 500。
