根本原因是php的max_execution_time限制，需修改php.ini中该值并重启php服务，或通过.htaccess、set_time_limit()等方法调整，同时注意upload_max_filesize、memory_limit和max_allowed_packet等关联限制。
phpmyadmin 提示最大执行时间超限，根本不是它自己的限制，而是 php 的 max_execution_time 在拦路——改这个值才能真正解决问题。
为什么改了 phpMyAdmin 配置没用
phpMyAdmin 本身不控制 PHP 执行时长，它只是运行在 PHP 环境里的一个 Web 应用。你看到的“Maximum execution time of X seconds exceeded”错误，来自 PHP 解释器对单个脚本运行时间的硬性截断，和 phpMyAdmin 的 config.inc.php 无关。
- 错误典型触发场景：导出大表、导入含大量 INSERT 的 SQL、执行复杂查询或重建索引
- 即使你把 phpMyAdmin 的
$cfg['ExecTimeLimit']设为 0（禁用），只要底层 PHP 的max_execution_time到了，照样中断并报错 - 宝塔面板用户注意：
PHP 设置 → 超时时间页面里调的其实就是这个值，但必须重启 PHP 服务才生效
改哪里？优先级从高到低
不是所有修改方式都等效，有些只在特定条件下起作用：
-
php.ini中修改max_execution_time = 300（单位秒），然后重启 PHP-FPM 或 Apache/Nginx —— 最可靠，全局生效 - 宝塔用户可在「网站 → PHP 版本 → 设置 → 配置文件」里直接编辑，保存后点「重载配置」按钮（注意：仅重载不够，必须点「重启服务」）
- 若无权限改
php.ini，可在 phpMyAdmin 所在站点根目录下加.htaccess（仅限 Apache）：php_value max_execution_time 300 - 在
wp-config.php或其他入口文件顶部加set_time_limit(300)—— 这是运行时覆盖，但可能被 PHP 安全模式或disable_functions拦住
容易被忽略的关联限制
光调 max_execution_time 不一定够，尤其导出/导入大文件时，还要同步检查：
-
upload_max_filesize和post_max_size：决定你能上传多大的 SQL 文件，phpMyAdmin 首页底部显示的 “Max: xxx MiB” 就是这两个值中的较小者 -
memory_limit：phpMyAdmin 加载并解析大 SQL 时会吃内存，设太小（如 128M）会导致Allowed memory size exhausted -
max_allowed_packet（MySQL 层）：如果 SQL 文件里有超长字段或大批量 VALUES，即使 PHP 允许跑完，MySQL 也会在执行阶段报ER_NET_PACKET_TOO_LARGE
命令行才是大文件的归宿
当你要处理几百 MB 甚至几个 GB 的 SQL，别再卡在 phpMyAdmin 里调参数了——它的 HTTP 架构天生不适合这事：
- 用 SSH 登录服务器，确保 SQL 文件已上传到可访问路径（如
/www/backup/large.sql） - 执行：
/www/server/mysql/bin/mysql -u root -p --max-allowed-packet=512M your_db_name - 这条命令绕过了 PHP 和 Web 服务器的所有超时与内存限制，只受 MySQL 服务端配置约束
- 导入前先手动建库、确认字符集（推荐
utf8mb4），避免中途因编码问题中断
真正麻烦的不是调哪个参数，而是你得同时盯住 PHP 层（max_execution_time、memory_limit）、Web 层（client_max_body_size for Nginx）、MySQL 层（max_allowed_packet）三道关卡——少一个，导入或导出就卡在不同位置，报错还各不相同。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
