MySQL连接空闲超时由服务端wait_timeout控制，Laravel不主动释放连接；其配置中timeout等参数仅影响连接建立或读写阶段，与空闲超时无关。
MySQL 连接空闲超时由数据库侧控制，Laravel 本身不主动“释放”连接
很多人以为 Laravel 有某个配置能“自动断开闲置连接”，其实不是。Laravel 的 DB 门面或 Eloquent 拿到的连接，本质是 PDO 实例，它默认复用、不主动关闭——只要 PHP 进程没结束，连接就一直挂着，哪怕你几分钟没查库。
真正起作用的是 MySQL 服务端的 wait_timeout（默认通常 28800 秒，即 8 小时），一旦连接空闲超过这个值，MySQL 会主动断开；下次再用时，PDO 才会报错：MySQL server has gone away。
- PHP-FPM 场景下，worker 进程常驻，连接极易复用并长期闲置
- CLI 命令（如
php artisan schedule:run）执行完就退出，连接自然释放，基本无此问题 - 连接池类扩展（如 Swoole + Coroutine MySQL）另当别论，不在 Laravel 原生 DB 层范畴
Laravel 配置里哪些参数会影响连接生命周期
config/database.php 中的几个关键项，看似管“超时”，实则各司其职，容易混淆：
-
'timeout' => 10：只控制连接建立阶段的 TCP 握手等待时间（单位秒），和空闲无关 -
'read_timeout' => 10和'write_timeout' => 10：仅对 MySQLi 驱动有效，PDO 不读取这两个值 -
'sticky' => true：只在事务中生效，让后续查询复用同一连接，反而延长闲置风险 -
'options'里加PDO::ATTR_TIMEOUT对 MySQL 无效，PDO 不透传该选项给 MySQL 协议
换句话说：Laravel 配置层没有“空闲超时”开关。想让连接更“短命”，得靠外部机制或代码干预。
手动释放连接的三种可行方式（按推荐顺序）
如果你确实遇到因长连接闲置导致的 MySQL server has gone away 或连接数打满，可选以下方法，注意适用场景：
- 最轻量：每次用完显式调用
DB::disconnect('mysql')，适合 CLI 命令或低频后台任务；但 Web 请求中频繁调用会抵消连接复用收益，不推荐 - 较稳妥：在中间件或请求结束时监听
kernel.handled事件，执行DB::disconnect()；需确保没人在后续（如日志、异常处理）再查库 - 最可控：改用
DB::connection()->getPdo()拿到原生 PDO 后，用$pdo = null置空变量，配合gc_collect_cycles()加速回收（PHP 8.0+ 更可靠）；但要注意 PDO 对象可能被其他地方引用，不能一概而论
示例（中间件中安全释放）：
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Event;
Event::listen('kernel.handled', function () {
DB::disconnect('mysql');
});
真正该检查的其实是 MySQL 和 PHP 的协同配置
与其在 Laravel 层“硬断”，不如确认底层是否合理：
- 查 MySQL 当前
wait_timeout：SHOW VARIABLES LIKE 'wait_timeout';，若设为 60，那连接最多活 1 分钟，PHP-FPM worker 就不得不频繁重连，增加握手开销 - PHP-FPM 的
pm.max_requests建议设为 500–1000，让 worker 定期重启，顺带清理所有残留连接 - 如果用云数据库（如阿里云 RDS、腾讯云 CDB），它们常把
wait_timeout改得极短（如 60 秒），这时必须同步调低 PHP 层的连接复用预期，或启用mysqlnd的自动重连（通过'options' => [PDO::MYSQL_ATTR_INIT_COMMAND => "SET SESSION wait_timeout=300"]不起作用，得靠驱动层）
空闲超时从来不是单点问题。Laravel 不管释放，MySQL 决定何时杀，PHP-FPM 控制进程寿命，三者节奏错位，才出问题。
