phpMyAdmin 不控制 SQL 执行时间，真正起作用的是 MySQL 的 max_execution_time（仅 SELECT，毫秒级）和 PHP 的 max_execution_time（页面脚本上限）；$cfg['ExecTimeLimit'] 仅为前端倒计时软限制，不影响实际执行。
phpmyadmin 本身不控制 sql 执行时间，它只是个前端界面；真正起作用的是 mysql 服务端的 max_execution_time（针对 select）和 php 的 max_execution_time（针对 phpmyadmin 页面响应）。改错地方会导致“明明调了却没用”。
确认你真正想限制的是哪一层？
很多用户以为在 phpMyAdmin 里点点就能延长慢查询时间，结果执行大表 COUNT 或 JOIN 还是超时——因为实际卡在 MySQL 层或 PHP 层：
- MySQL 5.7.8+ 支持
max_execution_time（毫秒），仅对SELECT生效，INSERT/UPDATE/DELETE不受控 - PHP 的
max_execution_time控制 phpMyAdmin 整个页面脚本运行上限，默认 30 秒，超时直接返回500 Internal Server Error或空白页 - phpMyAdmin 自身的
$cfg['ExecTimeLimit']是它前端加的软限制，单位秒，只影响“执行按钮点击后等待结果”的倒计时，不终止 MySQL 实际运行
修改 MySQL 的 max_execution_time（对 SELECT 查询生效）
这个变量是 SESSION 级或 GLOBAL 级，不能通过 phpMyAdmin 界面配置，必须进 SQL 栏手动设：
在 phpMyAdmin 的“SQL”标签页中运行：
SET SESSION max_execution_time = 60000;
或设为全局（需 SUPER 权限）：
立即学习“PHP免费学习笔记（深入）”；
SET GLOBAL max_execution_time = 60000;
注意：
-
max_execution_time单位是毫秒，60000 = 60 秒 - 仅对
SELECT语句有效，UPDATE、DELETE等 DML 语句完全无视该值 - 重启 MySQL 后 GLOBAL 值会丢失，如需持久化，得写进
my.cnf的[mysqld]段：max_execution_time = 60000 - 某些托管环境（如阿里云 RDS、AWS RDS）禁用
SET GLOBAL，只能用 SESSION 级临时生效
修改 PHP 的 max_execution_time（防止 phpMyAdmin 页面中断）
这才是多数人遇到“执行到一半白屏”或“Fatal error: Maximum execution time of 30 seconds exceeded”的根源。phpMyAdmin 是 PHP 脚本，它的整个请求生命周期受此限制：
- 找到 phpMyAdmin 所用的 PHP 配置文件（通常是
/etc/php/*/apache2/php.ini或/etc/php/*/cli/php.ini，取决于 Web 服务器） - 修改
max_execution_time = 300（例如设为 300 秒） - 如果用的是 PHP-FPM，还需检查
php-fpm.conf或 pool 配置里的request_terminate_timeout，它可能比max_execution_time更早杀掉进程 - 改完必须重启 Web 服务（
sudo systemctl restart apache2或sudo systemctl restart php-fpm）
临时调试可用 ini_set('max_execution_time', 300); 加在 phpMyAdmin 的 config.inc.php 开头，但不推荐长期使用——容易被更新覆盖。
别漏掉 phpMyAdmin 自带的 ExecTimeLimit（仅前端倒计时）
这个值只影响 phpMyAdmin 界面右下角那个“正在执行…（剩余 X 秒）”的提示，不影响后端真实执行。修改它不会让你的慢查询跑更久，但能避免误点“取消”：
编辑 phpMyAdmin 的 config.inc.php，添加或修改：
$cfg['ExecTimeLimit'] = 300;
单位是秒，设为 0 表示禁用前端倒计时。但它完全不干预 MySQL 或 PHP 的实际超时逻辑。
真正卡住你的，八成是 PHP 层的 max_execution_time 或 MySQL 的连接超时（wait_timeout、interactive_timeout），而不是这个前端小开关。
