php连接mysql“超时”主因是空闲连接被mysql主动断开（如close_wait状态），而php未检测复用导致“mysql server has gone away”；根本解决需代码层主动重建连接（如每8秒重连）、合理设wait_timeout为300秒、pdo显式配置attr_timeout控制握手超时。
PHP连接MySQL提示“超时”，绝大多数时候不是网络或服务器宕了，而是连接空闲太久被MySQL主动踢掉，而PHP还傻乎乎地拿它去执行SQL——结果报错“MySQL server has gone away”。
wait_timeout 为什么改了也没用
MySQL的wait_timeout默认是28800秒（8小时），看起来很宽裕。但这个值只在连接**真正空闲**时起作用；而PHP-FPM或队列worker这类长生命周期进程，哪怕只隔几秒执行一次SQL，中间那段“没发数据”的间隙，只要超过MySQL实际允许的空闲阈值（实测常为10秒左右），连接就可能被服务端关闭。
关键点在于：MySQL不看你“有没有PDO对象”，只看你“有没有发过包”。TCP连接上没数据流动，它就认为你挂了。
- 修改
wait_timeout后仍超时，大概率是因为客户端（PHP）根本没在连接上维持心跳 -
interactive_timeout对Web请求无效，它只影响mysql命令行这类交互式连接 - PHP端的
mysqli_connect_timeout或PDO::ATTR_TIMEOUT只管建连阶段，不管后续空闲期
PDO持久连接（PDO::ATTR_PERSISTENT）的真实行为
加了PDO::ATTR_PERSISTENT => true，并不等于“永不关闭”。它只是让PHP把连接放回连接池、而不是直接close()；但MySQL服务器仍然会按自己的wait_timeout清理这些“空闲连接”。下次复用时，如果连接已被MySQL断开，PDO不会自动重连，而是直接抛出异常。
更麻烦的是：这种断开发生在TCP层，状态常表现为CLOSE_WAIT（服务端已发FIN），而PHP进程还把它当活连接用。
- 持久连接无法规避MySQL端的空闲清理逻辑
- 它不能解决“连接被踢后复用失败”的问题，反而可能掩盖真实连接状态
- 高并发下还可能因连接池膨胀引发
max_connections耗尽
work模式下必须手动续命连接
ThinkPHP队列的php think queue:work --daemon或自写长任务脚本，进程不死，但连接会死。最稳妥的做法不是依赖配置，而是代码里主动干预：
- 每次执行SQL前，检查距离上次使用是否超过8秒（留2秒缓冲），超了就
unset($pdo)再new PDO(...) - 或者封装一个
getPdo()方法，内部用cache数组存PDO实例和时间戳，每次取用时判断并刷新 - 避免在循环体外长期持有PDO变量，尤其不要在
while(true)里只创建一次然后反复用 - 别依赖
mysqli_ping()或PDO::getAttribute(PDO::ATTR_SERVER_VERSION)做健康检查——它们本身也可能触发超时
真正该调的三个地方
与其花时间调大wait_timeout，不如盯住这三个实际生效的环节：
- PHP脚本内：用
set_time_limit(0)前先确认是不是真需要——很多“超时”其实是慢查询卡住，不是连接问题 - MySQL配置：把
wait_timeout设为300（5分钟）比8小时更合理，配合代码层主动重建，能更快暴露连接异常 - 连接建立时：PDO构造中显式传
['options' => [PDO::ATTR_TIMEOUT => 5]]，控制握手阶段等待上限，防止卡死在建连
连接空闲期没有心跳机制，这是MySQL的设计事实。所有“配置调大就能一劳永逸”的想法，都会在队列或守护进程场景下被打脸。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
