TP5.1慢查询卡住或报“MySQL server has gone away”说明仅配建连超时不够，须同步配置PDO::ATTR_TIMEOUT=5（查询执行超时）、PDO::ATTR_ERRMODE=PDO::ERRMODE_EXCEPTION（确保抛异常），并启用deploy=1+INIT_COMMAND触发连接健康检测，再结合EXPLAIN优化SQL本身。
TP5.1 配置了连接超时，但慢查询仍卡住或报错（如 MySQL server has gone away、SQLSTATE[HY000]: General error），说明你只解决了“连不上”的问题，没管“连上了却执行太久”或“连上后中途断开”的情况。关键要分清三类超时：建连超时、查询执行超时、连接空闲超时——它们由不同层级控制，漏掉任一环都会失效。
查清到底是哪类超时在作怪
先看日志里报错的具体类型：
- 出现
SQLSTATE[HY000] [2006] MySQL server has gone away→ 多是连接空闲太久被 MySQL 主动断开（wait_timeout触发），TP5.1 还在复用已失效的连接； - 请求卡死几十秒才失败，无明确错误 → 很可能是 SQL 执行本身超时（锁表、大字段、没索引），但 PDO 没设查询超时，PHP 脚本硬等到底；
- 刚访问就卡住几秒再报错 → 才是建连超时没配对，比如 DNS 解析慢或
connect_timeout没生效。
补全 PDO 查询执行超时（防慢 SQL 卡死）
TP5.1 的 database.php 中，仅配 'timeout' => 5 是无效的。必须用 PDO 原生参数：
在数据库配置的 params 数组里加：
-
PDO::ATTR_TIMEOUT => 5—— 单位秒，控制 SQL 发出后到返回结果的最大等待时间； -
PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION—— 必须开启，否则超时不会抛异常，框架无法捕获重试； - 别写成
'timeout'或'connect_timeout'，TP5.1 不识别这些键名。
堵住空闲连接断开导致的“假性超时”
MySQL 默认 wait_timeout = 28800（8 小时），但线上常调为 300 秒。若 TP5.1 连接池里的连接空闲超时，下次取出来直接执行就会报 gone away。解决办法：
- 配
'deploy' => 1开启连接复用（必须是整数1，不能写true或字符串）； - 加初始化命令：
PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4"，它会在每次取连接时自动执行，间接触发连接有效性检测； - 更稳妥的做法：在关键查询前手动 ping，例如
Db::getConnection()->getPdo()->getAttribute(PDO::ATTR_CONNECTION_STATUS)，或封装一个带健康检查的查询方法。
优化慢查询本身（治本）
超时只是兜底，不是替代优化。遇到频繁超时的 SQL，立刻做三件事：
- 用
EXPLAIN看执行计划，确认是否走了索引、有没有全表扫描； - 把
SELECT *改成明确字段，避免大文本/二进制字段拖慢网络传输； - 拆分复杂查询：比如含多个
JOIN和子查询的报表 SQL，改成分步查 + PHP 合并，或用临时表预聚合。
不复杂但容易忽略：超时参数得层层对齐——MySQL 服务端（wait_timeout）、PDO 客户端（ATTR_TIMEOUT）、PHP 脚本（max_execution_time），三者缺一不可。
