phpEnv解决MySQL server has gone away phpEnv超时设置-php教程-PHP中文网

“mysql server has gone away”错误主因是mysql的wait_timeout与php连接空闲时间不匹配，需修改mysql配置而非php.ini；确认方法为执行show variables like 'wait_timeout'；修复优先级：连接后set session、改my.ini中wait_timeout、避免长连接复用。

phpenv解决mysql server has gone away phpenv超时设置

phpEnv 环境下出现 “MySQL server has gone away” 错误，绝大多数不是 phpEnv 本身的问题，而是 MySQL 的 wait_timeout 与 PHP 连接行为不匹配导致的——你改了 phpEnv 的 PHP 配置，但没动 MySQL 的连接超时逻辑，就白调。

为什么 phpEnv 里改了 php.ini 没用？

phpEnv 是 Windows 下的 PHP 环境管理工具，它只管 PHP 进程和扩展（如 mysqli、PDO_MySQL），不管 MySQL 服务本身的配置。很多人在 phpEnv 的 php.ini 里狂加 default_socket_timeout 或 mysql.connect_timeout，结果错误照出——因为这些参数控制的是「建立连接」或「读取响应」阶段的超时，而 MySQL server has gone away（错误码 2006）90% 是连接建好后空闲太久，被 MySQL 服务端主动踢掉，跟 PHP 的 socket 超时无关。

default_socket_timeout 影响的是 PHP stream 层读写等待（比如大字段读取卡住），默认 60 秒；但它不会阻止 MySQL 服务端在 30 秒后直接断连
mysqli.reconnect = On 在 phpEnv 的 php.ini 里设了也基本无效：PHP 官方明确说明，mysqli 扩展自 PHP 5.5+ 起已废弃该选项，且即使开启也不处理空闲断连
phpEnv 启动的 MySQL 服务（如果自带）通常用的是默认配置，wait_timeout 很可能仍是 28800（8 小时），但某些精简版或一键包会悄悄改成 30–60 秒，必须查证

怎么确认是 wait_timeout 导致的？

别猜，直接进 MySQL 查当前连接的实际超时值。用 phpEnv 自带的 MySQL 客户端（或命令行）执行：

mysql -u root -p
SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';
SHOW PROCESSLIST;

重点看三件事：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

如果 wait_timeout 显示是 30 或 60，基本就是它 —— phpEnv 自带的 MySQL 常被魔改过
你的 PHP 连接在 SHOW PROCESSLIST 里 Time 列持续增长，快到 wait_timeout 值时断开，就是铁证
interactive_timeout 值再大也没用：PHP 的 mysqli_connect() 和 PDO 创建的是非交互式连接，只认 wait_timeout

phpEnv 环境下最稳的修复方式

优先级从高到低，推荐按顺序试：

连接成功后立刻执行 SET SESSION wait_timeout = 28800：对 mysqli 是 $mysqli->query("SET SESSION wait_timeout = 28800")；对 PDO 是 $pdo->exec("SET SESSION wait_timeout = 28800")。这招绕过所有配置文件限制，100% 生效
修改 phpEnv 管理的 MySQL 配置文件：找到 phpEnv 安装目录下的 mysql\my.ini（不是 PHP 的 php.ini），在 [mysqld] 段下加两行：wait_timeout = 28800 和 interactive_timeout = 28800，然后重启 MySQL 服务（phpEnv 控制面板里点「重启 MySQL」）
避免依赖长连接：在 CLI 脚本（如队列、采集）里，不要复用全局 $pdo 实例；每次操作前用 $pdo->getAttribute(PDO::ATTR_CONNECTION_STATUS) 检查，或干脆短连接 + try/catch + 重试

容易被忽略的坑：max_allowed_packet 和 phpEnv 的路径权限

同为 “server has gone away”，但错误源头可能是另一个：当插入或查询超大字段（如 JSON、HTML 片段）时，若超过 MySQL 的 max_allowed_packet 限制，也会报完全一样的错误，且不提示具体原因。phpEnv 默认的 my.ini 里这个值常是 1M 或 4M，不够用。

查当前值：SHOW VARIABLES LIKE 'max_allowed_packet';
临时改（重启失效）：SET GLOBAL max_allowed_packet = 64*1024*1024;
永久改：在 phpEnv 的 mysql\my.ini 的 [mysqld] 下加 max_allowed_packet = 64M，再重启 MySQL
额外注意：phpEnv 的 MySQL 服务如果是以 Windows 服务方式运行，修改 my.ini 后必须用管理员权限重启，否则配置不加载

真正麻烦的不是改哪，而是改完之后忘记验证——务必用 SHOW VARIABLES 和实际跑一次大 SQL 来确认生效。很多问题拖到上线才暴露，就是因为本地测试时没走真实数据量路径。